Date: Tue, 4 Jun 2024 21:44:57 +0000
This is just wrong.
When std::elide is admitted as the sole argument to a constructor then it should be admitted as the sole argument to that constructor.
The classes for which this doesn't work, the ones you're trying to save, are buggy. They are buggy before std::elide. They'll be buggy after std::elide. Patching the core language will not fix them, it'll only attenuate their brokenness so they're not broken in the face of std::elide (but they will still be broken in the face of other legitimately implementable types).
Moreover if this patch is implemented it will break/prevent legitimate, non-buggy uses of std::elide. It has all the qualities of a change which should not be applied: It makes life more convenient for people who write broken code without fixing their broken code, and makes life more difficult for people who write non-broken code.
--Robert
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]pp.org> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, June 4, 2024 17:29
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] std::elide
On Tue, Jun 4, 2024 at 9:58 PM Robert A.H. Leahy wrote:
>
> No.
>
> This class should not be special cased in the core language.
>
> Old, broken classes aren't worth trying to save in this manner.
>
> Just modify, reimplement, or wrap them.
Well. . . 9 out of 10 use cases for "std::elide" are that it should
fail to be the sole parameter type of a constructor. So to satisfy
those 90+ % of use cases, we should have an "std::elide" that fails
instantiation.
For the small minority of cases, where we want it to succeed in being
the sole parameter type of a constructor, we could have
"std::elide_nofail".
And as for the reluctance to change the core language for
"std::elide", well the core language and standard library are already
tangled.... I mean it really went to an extreme with having to include
a header file to use an operator (i.e. typeid). Plus there's core
language unique treatment for std::complex.
I don't think it's a big deal that "std::elide" would get special
mention in the the description of the core language.
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
When std::elide is admitted as the sole argument to a constructor then it should be admitted as the sole argument to that constructor.
The classes for which this doesn't work, the ones you're trying to save, are buggy. They are buggy before std::elide. They'll be buggy after std::elide. Patching the core language will not fix them, it'll only attenuate their brokenness so they're not broken in the face of std::elide (but they will still be broken in the face of other legitimately implementable types).
Moreover if this patch is implemented it will break/prevent legitimate, non-buggy uses of std::elide. It has all the qualities of a change which should not be applied: It makes life more convenient for people who write broken code without fixing their broken code, and makes life more difficult for people who write non-broken code.
--Robert
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]pp.org> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, June 4, 2024 17:29
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] std::elide
On Tue, Jun 4, 2024 at 9:58 PM Robert A.H. Leahy wrote:
>
> No.
>
> This class should not be special cased in the core language.
>
> Old, broken classes aren't worth trying to save in this manner.
>
> Just modify, reimplement, or wrap them.
Well. . . 9 out of 10 use cases for "std::elide" are that it should
fail to be the sole parameter type of a constructor. So to satisfy
those 90+ % of use cases, we should have an "std::elide" that fails
instantiation.
For the small minority of cases, where we want it to succeed in being
the sole parameter type of a constructor, we could have
"std::elide_nofail".
And as for the reluctance to change the core language for
"std::elide", well the core language and standard library are already
tangled.... I mean it really went to an extreme with having to include
a header file to use an operator (i.e. typeid). Plus there's core
language unique treatment for std::complex.
I don't think it's a big deal that "std::elide" would get special
mention in the the description of the core language.
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-06-04 21:45:04