C++ Logo


Advanced search

Subject: Re: Concepts & Incomplete Types
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2020-06-19 19:44:57

[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

STD-DISCUSSION list run by herb.sutter at gmail.com

Older Archives on Google Groups