Skip to content

CWG3003 [dcl.type.simple] Significance of "nam[ing]" a deducible template for CTAD #670

@hubert-reinterpretcast

Description

@hubert-reinterpretcast

Full name of submitter (unless configured in github; will be published with the issue): Hubert Tong

Reference (section label): dcl.type.simple, over.match.class.deduct

Link to reflector thread (if any): N/A

Issue description:
The wording of https://eel.is/c++draft/dcl.type.simple#3 successfully achieves avoiding dependent templates for CTAD, but the wording fails to be explicit enough. In particular, naming a template template parameter names a template template parameter (not a deducible template).

The over.match.class.deduct wording similarly relies on this notion of naming a deducible template (https://eel.is/c++draft/over.match.class.deduct#3 starts with "the guides of the template named by the simple-template-id of the defining-type-id").

Implementations appear to allow deduction from a template template parameter but also appear to be unprepared for the implications of doing so.

Clang, GCC, EDG, and MSVC all accept (https://godbolt.org/z/8Kevd9dze):

template <template <typename> class TT>
void f() { TT x(42); }

template <typename T> struct A { A(T); };

void g() { f<A>(); }

Clang, GCC, and EDG crash; MSVC rejects (https://godbolt.org/z/Pd9o76cWo):

template <typename T> struct A { A(T); };

template <typename T, template <typename> class TT = A>
using Alias = TT<T>;

template <typename T>
using Alias2 = Alias<T>;

void h() { Alias2 a(42); }
void h2() { Alias a(42); }

Suggested resolution:
Add a note to the effect that naming a template template parameter does not name a deducible template.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions