https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125605
--- Comment #4 from songb432 at gmail dot com ---
(In reply to songb432 from comment #3)
> (In reply to Jonathan Wakely from comment #2)
> > It's unclear which part you think is a bug.
>
> Umm, don't know how to say that:
> when I typed something like `template <class Alloc> concept
> has_usable_pointer = Cpp17NullablePointer<typename Alloc::pointer>;`,
> the compiler must ensure that `has_usable_pointer<my_allocator>` is true if
> and only if `my_allocator` indeed has a member typedef
> `my_allocator::pointer` (which is checked first) and `my_allocator::pointer`
> satisfy the concept `Cpp17NullablePointer`,
> but the current GCC compiler just ignores `my_allocator::pointer`.
> `Example2, Example2_, Example3` are such cases.
>
> In details, for `Example2`, `sad_nested_type<int>` should fail because it
> fails `typename T::type`; for `Example2_` and `Example3`, the compiler
> errors are wrong. `Example2_` should report `no candidate` instead of
> `ambiguous`. `Example3` should just compiles with no error.
>
> While for `Example1`, I think I was wrong. There's nothing wrong with
> `Example1`, that static assertion should pass. Because `T::value` in the
> definition of `concept A` is just the same as `template<typename T> concept
> Q = T::value;` and `template<typename T> concept A = Q<T> || true;`.
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.
