Date: Sat, 20 Jun 2020 04:22:14 +0300
On Sat, 20 Jun 2020 at 03:45, Paul Mensonides via Std-Discussion
<std-discussion_at_[hidden]> wrote:
>
> [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.
Well, quoth:
/* snippety */
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.
/* snap*/
This is already the case with any trait. Any C++98 SFINAE trick will run
head-first into this same problem. Concepts don't change that.
Am I missing something?
<std-discussion_at_[hidden]> wrote:
>
> [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.
Well, quoth:
/* snippety */
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.
/* snap*/
This is already the case with any trait. Any C++98 SFINAE trick will run
head-first into this same problem. Concepts don't change that.
Am I missing something?
Received on 2020-06-19 20:25:38