On 07/01/2023 20.59, Giuseppe D'Angelo via Std-Proposals wrote:
> On 07/01/2023 19:52, Frederick Virchanza Gotham via Std-Proposals wrote:
>>
>> When I first started wondering about the implications of this core
>> language change, I first thought that it might break old code that
>> relies on SFINAE, but I tried writing a template function with
>> "std::enable_if" and I don't actually think that this change to the
>> core language would break any SFINAE achieved with "std::enable_if".
>
>
> This would break:
>
>> template <typename T, typename Enable = void>
>> constexpr bool x = false;
>>
>> template <typename T>
>> constexpr bool x <T, std::void_t<decltype(std::declval<T>()->size())>> = true;
>>
>> static_assert(!x<std::string **>);

We know that about any change to the rules of C++ will
change SFINAE results such as shown above, but that is
usually acceptable. Your example checks whether one
can use "x->size()" on "std::string **x", and the answer
was "no" before and now is "yes" --- exactly what the
proposal intends to achieve. So this particular example
is not a counterargument against the proposal.

Given the presence of references in C++
(which usually save one level of explicit pointer
indirection), I've very rarely come across the need
to handle two or more pointer levels, so I'm not
seeing that this feature has a good bang-for-the-buck
ratio (specification-wise, implementation-wise,
teaching-wise etc.)

Jens