I roughly read the proposal and found some weirdness in it.

1. operator== should be specified instead of operator!=. As of C++20 there're rewritten candidates.

2. The bases() member function should return a range, not a pair. It's sad story that equal_range member functions of containers don't return ranges and we can't fix them. Perhaps it's still possible to fix flat container adaptors with a defect report at this moment.

Thanks,

F.v.S.

From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Monday, April 15, 2024 15:30
To: std-proposals <std-proposals@lists.isocpp.org>
Cc: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>
Subject: [std-proposals] std::elide

For the past month, I've been considering whether we should:

    (A) Add a new standard library class, std::elide

Or:

    (B) Add a new member function named "emplace_invoke" to
std::optional, std::variant

Or:

    (C) Do both A and B

A and B both allow us to do the following: Emplace an
unmovable-and-uncopyable PRvalue into an std::optional, std::variant.

The difference is that A allows us to continue to use pre-existing
code. Third party libraries, such as Boost, contain header files which
have code that uses the original 'emplace' function, and so all of
these pre-existing header files can be used without change if we opt
for A.

Since A can do everything that B can do, there is no need to also
implement B -- although I don't object to simply having it as an
alternative. But for the sake of not making the Standard any bigger
than it needs to be, perhaps just go for A by itself.

So here's the latest paper which I'm considering getting a PxxxxR0 number for:

    http://www.virjacode.com/papers/elide.htm
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals