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.