https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125605
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Blocks| |103524
Resolution|--- |INVALID
CC| |ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka <ppalka at gcc dot gnu.org> ---
> 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.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
