Pfthb

I have this nested templated struct:

template <typename... Ts>
struct A

 template <unsigned i>
 struct B
 
 int b;
 ;
;

That compiles fine.

Then I try to define this function.

template <unsigned i, typename... Ts>
void foo(A<Ts...>::B<i> var)

 std::cout << var.b << std::endl;

For some reason I don't completely understand, that won't compile. I had to change it in the following way for it to work.

template <unsigned i, typename... Ts>
void foo(typename A<Ts...>::template B<i> var)

 std::cout << var.b << std::endl;

But then, when I call it like so:

A<int, float>::B<0> var = 0;
foo(var);

It says that template parameter i cannot be deducted.

I can make it work by adding the template arguments explicitly to the function call:

A<int, float>::B<0> var = 0;
foo<0, int, float>(var);

Why is that? How can I make it so I don't have to specify the template parameters in the function call?

Try the code: https://repl.it/repls/LavenderDefiantOctagons

Because the standard says so.

The standard says so because inverting arbitrary compile time maps is equivalent to Halt.

It is equivalent to Halt because template metaprogramming is Turing complete.

It is Turing complete because it is actually hard to make a useful programming language that isn't Turing complete; it happens by accident, and avoiding it leads to a language that requires annoying workaround for seemingly simple things.

So the problem in general, of determining which A the A<int, float>::B<0> is from and reversing that mapping, is hard, so the C++ standard says the compiler doesn't try.

If you write your own mapping you can do it. First, you have to realize that B types have no "hair" in that there is nothing about the type of B that attaches it back to the type of A used to create it. We can add "hair":

template<class...Ts>
struct A 
 template<unsigned i>
 struct B 
 using daddy = A;
 int b;
 ;
;

now we can find A from the type of B<?>.

Next let's add some inverse maps:

 template<class...Ts>
 struct types_t using type=types_t;;

 template<class X>
 struct get_types;
 template<class X>
 using get_types_t=typename get_types<X>::type;
 template<template<class...>class Z, class...Ts>
 struct get_types<Z<Ts...>>:types_t<Ts...>;
 template<class B>
 struct get_B_index;
 template<unsigned i, template<unsigned>class B>
 struct get_B_index<B<i>>:std::integral_constant<unsigned, i>;

and from this we can get A's template arguments from B:

 template<class...Ts, unsigned i>
 void foo( types_t<Ts...>, std::integral_constant<unsigned, i>, typename A<Ts...>::template B<i> var ) 
 
 template<class B>
 void foo( B b ) 
 using types = get_types_t< typename B::daddy >;
 using index = get_B_index< B >;
 return foo( types, index, b );
 

Live example

Template argument deduction can't deduce anything that appears in a nested-name-specifier. For example, it won't allow T to be deduced from a parameter of type typename Foo<T>::bar. I believe that the reason for this is that such deduction is not possible in general; there can always be partial specializations of Foo that define bar to be some arbitrarily complicated typedef.

The workaround is to define the nested type as an unnested type then bring it in using a typedef, but use the original unnested name for deduction:

template <unsigned i, typename... Ts>
struct A_B int b; 

template <typename... Ts> 
struct A 
 template <unsigned i> using B = A_B<i, Ts...>;
;

template <unsigned i, typename... Ts>
void foo(A_B<i, Ts...> var);

In your specific case the nested type B is uniquely attached to the specific specialization of the enclosing type A. There's one-to-one correspondence between various Bs and their enclosing As. So, theoretically it should be possible to deduce the arguments of A from a specific B.

However, in general case the nested type name might refer to an alias (e.g. typedef-name), as opposed to a genuinely new type name (as in your example). In case of nested alias the 1:1 correspondence no longer holds, which is demonstrated by the examples in other answers.

The language specification does not distinguish between these two situations (a genuinely new nested type vs. a nested alias), so it opts for the "common denominator" approach and just always treats the enclosing template parameters as non-deduced context.