[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y<typename T::type>" does not check that T::type actually exists

[ppalka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419

--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the concept-id X<int>, they appear to be substituting {int} into X's constraint-expression instead of into the normal form of X's constraint-expression.
> 
> Isn't this situation exactly analogous to `std::void_t`?
> 
>   template<class T> using void_t = void;
>   template<class T> auto foo(T t) -> void_t<typename T::type>;  // SFINAEs
> away
>   template<class T> auto foo(T t) -> int;  // this is the only viable
> candidate
>   static_assert(std::same_as<decltype(foo(1)), int>);
> 
> The language has definitely decided that you can't preemptively fold
> `void_t<some-dependent-expression>` down to `void`;

True, that 
I don't think you should
> be allowed to preemptively fold `Y<some-dependent-expression>` down to
> `true`, either.
> I don't know for sure that Clang/MSVC have been authoritatively dubbed
> righteous, but their behavior certainly seems, to me, more consistent and
> useful than GCC's.

(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the concept-id X<int>, they appear to be substituting {int} into X's constraint-expression instead of into the normal form of X's constraint-expression.
> 
> Isn't this situation exactly analogous to `std::void_t`?
> 
>   template<class T> using void_t = void;
>   template<class T> auto foo(T t) -> void_t<typename T::type>;  // SFINAEs
> away
>   template<class T> auto foo(T t) -> int;  // this is the only viable
> candidate
>   static_assert(std::same_as<decltype(foo(1)), int>);
> 
> The language has definitely decided that you can't preemptively fold
> `void_t<some-dependent-expression>` down to `void`; I don't think you should
> be allowed to preemptively fold `Y<some-dependent-expression>` down to
> `true`, either.

I see what you mean, but I think the constraint normalization process as
currently specified forces us to effectively perform such folding. 
Specifically in the definition of an atomic constraint
([temp.constr.atomic]p1):

  An atomic constraint is formed from an expression E and a mapping from the
template parameters that appear within E to template arguments that are formed
via substitution during constraint normalization in the declaration of a
constrained entity.

the parameter mapping of an atomic constraint is defined to consist only of the
template parameters that _appear within E_.  In this case E is just 'true',
which doesn't depend on any template parameters, so the normal form of
Y<typename T::type> is just 'true (with empty parameter mapping)', which is
trivially satisfied for all T.

In order to achieve the behavior that you expect, IIUC this definition would
need to be changed to say that the parameter mapping of an atomic constraint
includes all in-scope template parameters and not only those that appear within
the expression.