Explicit template instantiation of nested types

[Tomaqa]

Bugzilla Link	49133
Version	11.0
OS	Linux
CC	@dwblaikie,@DougGregor,@zygoloid

Extended Description

Clang does not accept explicit class template instantiation of a nested type.

Minimal example:

template <typename>
struct Tp {
    using Alias = Tp;
};

/// All should be valid and equivalent
extern template struct Tp<int>;             //< works
extern template struct Tp<int>::Tp;         //< fails
extern template struct Tp<int>::Alias::Tp;  //< fails

error: explicit instantiation of non-templated type 'Tp<int>'

The inst. of nested types should be standard-compliant as well as the first one.
Also, the error message is quite confusing.
Works in GCC.

https://stackoverflow.com/questions/34506356/using-typedef-in-template-instantiation-and-extern-template-declaration/34506955#34506955
https://stackoverflow.com/questions/11414817/code-duplication-between-typedefs-and-explicit-instantiations

[zygoloid]

Clang is enforcing [temp.explicit]p4 (http://eel.is/c++draft/temp.explicit#4), which it appears other compilers (GCC, MSVC, even EDG) don't appear to implement.

However:

-- the diagnostic here is terrible; we shouldn't claim that Tp<int> is a "non-templated type"
-- the wording of the rule, taken literally, would allow these cases, although the literal interpretation really doesn't make any sense

I've asked the C++ core working group to try to find out what the intent of this rule was.

[Tomaqa]

I do not understand: the rule "If the explicit instantiation is for a class or member class, the elaborated-type-specifier in the declaration shall include a simple-template-id" is not violated IMO, neither by Tp<int>::Tp nor Tp<int>::Alias::Tp, since they include Tp<int>.

The motivation of allowing such cases is important here, also mentioned in a comment within the thread I supplied: https://stackoverflow.com/questions/39919607/explicit-template-instantiation-using-alias/39920067#comment113949448_39920067

To be more specific: consider class hierarchy based on mixins, where it is necessary to use typedefs to make the code readable. Example:

template <typename T> struct Base { /*...*/ };
template <typename B> struct Mixin1 : B { /*...*/ };
...
template <typename B> struct MixinN : B { /*...*/ };

template <typename T> using Class1 = Mixin3<Mixin1<Base<T>>>;

template <typename T> using Class2 = Mixin7<Mixin4<Class1<T>>>;

extern template struct Class1<int>::Base;
extern template struct Class1<int>::Mixin1;
extern template struct Class1<int>::Mixin3;

extern template struct Class2<int>::Mixin4;
extern template struct Class2<int>::Mixin7;

Without this being allowed, the instantiation becomes living hell if one has to always supply the full name of each class.
In addition, if, for example, Mixin3 would be dropped from the Class1 in the future, one would have to update almost all instantiations, instead of just dropping the inst. of Mixin3.

I am not sure if Class<i> are required to be structs, and not aliases, in the instantiation.
But if so, it is no problem to substitute them with structs. The important thing is allowing the nested types.

[zygoloid]

I do not understand: the rule "If the explicit instantiation is for a class or member class, the elaborated-type-specifier in the declaration shall include a simple-template-id" is not violated IMO, neither by Tp::Tp nor Tp::Alias::Tp, since they include Tp.

Yes, as I said, the code is valid if you take the rule literally, but the rule as written pretty clearly doesn't reflect any sensible intent, so should not be read literally.

It seems most likely to me that the intent of this rule is that you must express the name of the template specialization in the "normal" way (that is, when instantiating a class template specialization the terminal name in the elaborated-type-specifier should be required to be part of a simple-template-id naming the class template), but the wording fails to capture that intent, allowing cases such as your use of the injected-class-name and things like this:

template<typename T> struct A {};
template<typename T> using id = T;
using U = A<int>;
struct V { using W = A<int>; };

template struct id<V>::W::A;

... which were very likely never supposed to be valid. (The template-id appearing here has nothing to do with the explicitly instantiated class.)

Without this being allowed, the instantiation becomes living hell if one has to always supply the full name of each class.

For what it's worth, I agree; when I reported this to the C++ committee I suggested that we should remove the rule in question. I think it'd even make sense to allow things like

template Class1<int>;

(which, notably, MSVC already accepts and treats as template struct Mixin3<Mixin1<Base<T>>>;).

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (Tomaqa)

| | | | --- | --- | | Bugzilla Link | [49133](https://llvm.org/bz49133) | | Version | 11.0 | | OS | Linux | | CC | @dwblaikie,@DougGregor,@zygoloid |

Extended Description

Clang does not accept explicit class template instantiation of a nested type.

Minimal example:

template <typename>
struct Tp {
    using Alias = Tp;
};

/// All should be valid and equivalent
extern template struct Tp<int>;             //< works
extern template struct Tp<int>::Tp;         //< fails
extern template struct Tp<int>::Alias::Tp;  //< fails

error: explicit instantiation of non-templated type 'Tp<int>'

The inst. of nested types should be standard-compliant as well as the first one.
Also, the error message is quite confusing.
Works in GCC.

https://stackoverflow.com/questions/34506356/using-typedef-in-template-instantiation-and-extern-template-declaration/34506955#34506955
https://stackoverflow.com/questions/11414817/code-duplication-between-typedefs-and-explicit-instantiations

[shafik]

Implementations still diverge here: https://godbolt.org/z/zGfG3zqss

@zygoloid do you have a cwg issue number?

[zygoloid]

@zygoloid do you have a cwg issue number?

There's no CWG issue yet; my previous mail didn't get any attention at all. I've pinged it, we'll see if anyone has thoughts now.

[cor3ntin]

https://cplusplus.github.io/CWG/issues/3006.html