Or... and hear me out...
You don't do std::elide, add a new interface that does the function call explicitly and it works for 100% of the cases, no core language exceptions, and it is actually clean.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]pp.org> On Behalf Of Frederick Virchanza Gotham via Std-Proposals
Sent: Tuesday, June 4, 2024 23:30
To: std-proposals_at_lists.isocpp.org
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_gmail.com>
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_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals