How to expose inherited constructors when using nested templating?

Consider this simple class derived from std::variant:

#include <string>
#include <variant>

class my_variant : public std::variant<int, std::string>
{
    using variant::variant;
public:
    std::string foo()
    {
        return "foo";
    }
};

Notice, I am deliberately adding using variant:variant so that constructors from the base class are exposed in the derived class. If you do not do this, instances of my_variant class will not work with operator= without a bunch of re-definitions.
This compiles just fine.

Now let's start turning it into a template step-by-step.

template <typename TChr>
class my_variant : public std::variant<int, std::string>
{
    using variant::variant;

public:
    // Changed to templated return type, compiles fine
    std::basic_string<TChr> foo() 
    {
        return "foo";
    }
};

Here, the only change is that we make use of the template parameter in the foo() method. Everything still compiles fine.

And now this:

template <typename TChr>
class my_variant : // Changed to templated base class
    public std::variant<int, std::basic_string<TChr>> 
{
    // Now this line won't compile !!
    using variant::variant; 

public:
    std::basic_string<TChr> foo()
    {
        return "foo";
    }
};

As soon as I make use of the template parameter to describe the base class, I am getting the following compiler error:

'variant': is not a class or namespace name 

for this line: using variant::variant;

I do not fully understand why this specific change causes a problem. So far I was thinking in the direction that maybe using variant::variant without specifying its template signature is a problem, so I tried this:

template <typename TChr>
class my_variant :
    public std::variant<int, std::basic_string<TChr>>
{
    // Added templating here, still fails with the same error message.
    using variant<int, std::basic_string<TChr>>::variant; 

public:
    std::basic_string<TChr> foo()
    {
        return "";
    }
};

Doing so generates the same error message, so I must be doing something wrong.

Compiler is MSVC 2022, C++20 mode.

> [...] So I must be doing something wrong!!

Since in the last my_variant, the parent std::variant depends upon the class template argument, you also need the constructor from the correct parent

template <typename TChr>
class my_variant : public std::variant<int, std::basic_string<TChr>> 
{
    using std::variant<int, std::basic_string<TChr>>::variant;
    //    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
public:
    std::basic_string<TChr> foo()
    {
        return "foo";
    }
};

That has been mentioned, also have a read here, for more about your approach:

https://stackoverflow.com/questions/2034916/is-it-okay-to-inherit-implementation-from-stl-containers-rather-than-delegate

To expand on JeJo's answer:

The key idea here is name lookup. Whenever you use a name in C++, the compiler must decide what entity that name refers to. Sometimes it can just look for a declaration in the current scope (or one of its parents), e.g.

void foo() { return foo(); }
                    ^~~

There's no foo declared in the current scope, but there's the function named foo in the parent scope, so we take that.

Inside a class or class template, another possibility kicks in: the injected-class-name.

int Foo = 42;
struct Foo {
    void f(Foo&);
           ^~~

Here, the name Foo means "this class right here, Foo," even though there are multiple declarations of a name Foo in the parent scope. (C++ allows you to have a type and a variable with the same name at namespace scope, because C compatibility: think stat(3).) We call this the injected-class-name of Foo.

Injected-class-names also apply to base classes:

int Base = 42;
struct Base {};
struct Foo : Base {
    void f(Base&);
           ^~~~

There's no Base in the current scope, so we look in the parent scope, which is the base-class scope. There is a Base in that scope: the injected-class-name that means "this Base right here." So this code is also okay.

Inside a class template, the injected-class-name refers to "this instantiation of Foo right here." So:

template<class T>
struct Foo {
    void f(Foo&);
           ^~~

this Foo means the same thing as if it had said Foo<T>.

But remember, all of this is a subsystem of name lookup. The other relevant quirk of name lookup is that during phase 1 of two-phase lookup (that is, before template instantiation), name lookup never peeks into dependent base classes. (It can't, because they're dependent on template arguments, and we don't know those arguments yet.) So (Godbolt):

template<class T>
struct Foo : NDBase<int>, DBase<T> {
    void f(NDBase&, DBase&);
           ^~~~~~   ^~~~~

The reference to NDBase is OK: that's the injected-class-name of NDBase<int> inherited from NDBase<int>. The reference to DBase is bad: that's not the injected-class-name of DBase<T>, because DBase<T> is a dependent base, so Foo isn't going to look up anything in it.

We can tell name lookup that DBase is supposed to be looked up as a member by prefixing it with Foo:: (for most kinds of members, prefer this->). Of course then we also need to tell the parser that this dependent name is going to be a typename, not a variable/function/etc.:

template<class T>
struct Foo : NDBase<int>, DBase<T> {
    void f(NDBase&, typename Foo::DBase&); // OK
};

In your original example, you can get away without the typename prefix because using ... is already a typename-only context. In other words, you can do either:

using my_variant::variant::variant;
  // express that `variant` is a member, so look it up in
  // the dependent base and find it as an injected-class-name

using std::variant<int, std::basic_string<TChr>>::variant;
  // avoid injected-class-names entirely, and just name the
  // base type relative to the parent scope

But you can't just say

using variant::~~~~

because the compiler doesn't know what variant means in this scope. (Because it refuses to peek into the dependent base class in order to find that there's a matching injected-class-name visible in there.)