There's no grinding to a halt.

Classes with unconstrained unary constructors are just broken, as you've discovered.

The solution isn't to hack around in the language to make them not broken for one novel library type, the solution is to fix the types.

The paper should propose a library type and nothing more.

--Robert
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Saturday, June 8, 2024 10:15
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 10:45 PM Robert A.H. Leahy wrote:
>
> 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.


We can't grind a proposal to a halt and throw it in the bin just
because 10% of use cases go against the other 90% of use cases.

We need to meet somewhere in the middle.

If we were to design a computer programming language from scratch
today in 2024, we'd probably come out with something beautiful and
elegant -- but that's not what we're doing here on this mailing list.
We have to take K&R C, which became C89, which became C++, which
became C++11, and which is now C++23, and try to make feature upgrades
to it without totally upheaving the language so severely that compiler
vendors become dissuaded from complying with the Standard.

That's what "std::elide" is pretty much all about -- we're
compensating for oversights and inadequacies that crept in earlier in
the timeline (back when C++ became C++11).

Progress, not perfection. So here's the changes I've made for the next
revision of the paper:

R2 => R3 (Draft A)
      * Two separate classes "std::elide" and "std::elide_c1" so that
the programmer can use the latter in a scenario where a template
constructor is desired to be instantiated with an elider as its sole
parameter type.
      * Chaining of eliders is now possible with operator().
      * "tag_elide" renamed to "tag_tempfail_ctor_soleparam" to make
it generic so that it can be used for other purposes in the future.
      * The example of deriving a class from "std::elide" is removed
as it’s unnecessary because we have "std::elide_c1".

Here's the latest paper:

    http://www.virjacode.com/papers/p3288.htm

It's called "R3 (Draft A)" because I haven't emailed yet to the
vice-chair Nevin, as someone might point out a typo right away. I'll
submit it to Nevin as R3 in a couple of days.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals