Re: C++ PATCH for non-type constrained-type-specifiers

[Andrew Sutton <andrew dot n dot sutton at gmail dot com>]

> I started looking at allowing non-type constrained-type-specifiers in auto
> deduction and then realized that we didn't handle them in function
> parameters either.  Fixing that brought home to me the oddity of having a
> type-specifier stand in for a non-type.  Mind weighing in on that on the
> core reflector?

That is a little weird. The non-type placeholders should be
id-expressions that name a concept. And template placeholders would be
template-names.

I'll create an issue for it. I need to email Mike Miller and figure
out how issues processing will work. But not until I'm out of the
weeds for the semester.


> I also wonder why we have two different ways of expressing a
> constrained-type-specifier in the implementation: a constrained
> template-parameter (TYPE_DECL, is_constrained_parameter) and a constrained
> auto (TEMPLATE_TYPE_PARM).  Why not represent them the same way?

It's probably a historical distinction. We didn't get concepts as
placeholders until much later in the standardization process.

But with auto template parameters on the horizon, it might be
worthwhile to maintain the distinction. That feature adds a wonderful
little ambiguity:

template<auto X> struct S;

would declare a non-type template parm whose type is deduced from a
template argument.

template<typename T> concept bool C = true;
template<C X> struct S;

Is C a constrained placeholder (as per a reasonable interpretation of
parameter-declarations), or does it declare a type parameter (as per
the TS)? It's going to end up being the latter.

Combining the representations might make it difficult to tease out
intent later. But that's just me speculating.


Andrew