[forwarded to list, apologies for the direct reply Ville]

On 6/19/2020 5:25 PM, Paul Mensonides wrote:
> On 6/19/2020 4:53 PM, Ville Voutilainen wrote:
>> On Sat, 20 Jun 2020 at 01:12, Paul Mensonides via Std-Discussion
>
>>> template<std::derived_from<base> T>
>>> std::enable_if_t<sizeof(T)> f(const T*) { }
>>>
>>> which seems unfortunate.
>>>
>>> Thoughts?
>>
>> Plenty. Concepts weren't designed to solve this problem in any way
>> different than
>> template equivalence in general wasn't. You can't write a metaprogram
>> that detects
>> an incomplete type if that metaprogram is ever run later with a
>> complete type,
>> because ODR and the general notion of what [temp.point]/7 is about.
>>
>> I understand it's unfortunate. We need to think carefully about a
>> solution for this problem.
>
> The issue is not this particular case but rather *any* naive
> "unprotected" use of any concept that requires a complete type in a
> function template is a time bomb to other completely unrelated code.
> E.g. the presence of a declaration such as
>
> template<std::derived_from<does_not_matter> T> void f(const T&);
>
> is a automatic timb bomb on the name "f" even in completely unrelated
> contexts provided the above declaration is visible at the point of an
> "f" function call.
>
> I imagine that most concepts will need complete types, which, in turn,
> would mean that most template functions would need extra layers of
> top-level instantiation-free SFINAE to avoid the side-effects induced by
> instantiation and concept evaluation should it ever be implicitly tested
> by the compiler with an incomplete type.
>
> Moral of that story is virtually every constrained function template
> should do this. "Unfortunate" indeed.
>
> Regards,
> Paul Mensonides