Using templates to pass undeclared types

template <typename T>
void call(T in){}

struct test{
  using type_t = int;
  void f() {
    type_t a = 1;
    call(a);
  }
};

int main(){
 test t;
 t.f();
 return 0;
}

Above compiles normally. My question is how can the compiler deduce T to type_t correctly? type_t is only available inside the scope of struct test.

i.e if change call to

void call(type_t in){}

I get the expect error message of 'type_t' was not declared in this scope.

type_t being declared in test is not a problem. For example:

template <typename T>
void call(T in) {}

struct test {
    using type_t = ...;
    void f() {
        // deduces:                 T = test::type_t
        // implicitly instantiates: void call<test::type_t>(test::type_t)
        call(type_t{});
    }
}

Even if type_t was private within test, this would work just fine, because access-specifiers don't prevent us from instantiating templates.

In your example, it's even less of an issue, because type_t = int, and type_t isn't a distinct type but an alias. As a result, the compiler deduces T = int and instantiates call<int>(int).

type_t, here, is a public type alias (because structs' default visibility is public). It is accessible from the outside if needed.

And even then, I don't think it would change anything if it weren't public.

You're confusing types that are accessible to the people who use your API, and types that are accessible to the compiler (which is every type).

This distinction was used in C to circumvent the lack of encapsulation: user's couldn't create instances "manually" but were expected to provide one in functions; they could only get an instance through specific functions (think fopen).

It seems to me that you're kind of confusing names with the things they refer to.

For example, in this code:

struct test{
  using type_t = int;
  void f() {
    type_t a = 1;
    call(a);
  }
};

type_t is a name. It has a scope almost like any other name, and outside that scope the compiler won't use it (not because it couldn't, but because the whole point of scopes is the limit the visibility of names so it won't).

Trying to use that name outside that scope, like: void call(type_t in){} is bound to fail simply because the compiler can't find that name. We can make it work by 1) rearranging the code so type_t has been declared by the time we try to use it in call, and 2) adding a scope resolution operator so the compiler can/will find it:

struct test{
  using type_t = int;
  void f();
};

void call(test::type_t in) 

void test::f() {
  type_t a = 1;
  call(a);
}

So, to have access to the names, we just have to arrange the code so each name has been declared before we try to use it. In this case, there's enough interaction between call and test that we need to arrange everything in a specific order for it to work (a decent sign that in real life, this may not be a great design).

That's not how the original code worked though. It didn't share the name type_t from test to call. It just declared type_t as an alias for int, and then passed a parameter of that type to call, which resulted in call<int> being instantiated and used. That doesn't depend on the name type_t being visible to the template at all though. For this, the compiler only really cares about the underlying type being referred to, not the name.

For that matter, the type we use to instantiate a template doesn't even need to have a name at all. For example:

template <class T>
void func(T t) { t(); }

struct foo {
    foo() {
        auto unknown_t = [] { std::cout << "lambda!\n"; };

        func(unknown_t);
    }
};

A lambda expression basically creates a class that doesn't even have an actual name-but we can still use its type to instantiate a template just fine.

Summary

So, if we use a name, that name has to be visible where we use it (has been seen by the compiler, and is in scope). But the name of a type doesn't have to be visible for that type to be used to instantiate a template. In fact, the type doesn't need to have a name at all.