https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125605
--- Comment #7 from songb432 at gmail dot com ---
(In reply to Patrick Palka from comment #5)
> > There's a ridiculous point: if I change `template <class> concept X = true`
> > into `template <class T> concept X = requires { typename
> > type_identity_t<T>; };` or something else concerning eventually a truly
> > type dependent constraint (the evaluated result is truly type dependent),
> > then everything (including that `has_usable_pointer` example) works
> > perfectly.
>
> GCC is behaving correctly here, even though it's somewhat surprising at
> first. The main thing is that the parameter mapping of an atomic constraint
> involves only the template parameters that are _used_ in the atomic
> constraint expression. The concept C = true doesn't use any of its template
> parameters, so during normalization we effectively ignore its corresponding
> template arguments.
>
> That's why in https://eel.is/c++draft/temp.constr#normal-example-1 the
> concept A is defined as
>
> template<typename T> concept A = T::value || true; // uses T
>
> If it was defined as just
>
> template<typename T> concept A = true;
>
> then normalization of C wouldn't be erroneous since the parameter mapping
> would be empty and we wouldn't form the invalid type V&* anywhere.
>
> Doing `= requires { typename T; }` instead of `= true` is the recommended
> approach if you want your examples to work in the way you expect.
There's another issue: GCC 10 ~ 16 all behaves the same on those examples, but
Clang 17 ~ 21 behaves (the way I expect) different from GCC, but but, Clang 22
behaves the same with GCC. I'm not sure if Clang 22 did think the behaviour of
Clang 17 ~ 21 has any bug, since I didn't find anything concerning this.
See that on https://godbolt.org/z/zdosxqdf1
