I also don't see a need for a language change - but the need for std::elide
as a vocabulary type is obvious to anyone who's written it.

It is a sibling of std::overload in that respect.

We should standardize it just because there is one good way to write it and
it's 5loc.

On Thu, May 30, 2024, 20:28 Robert A.H. Leahy via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Why would we create a new interface for invocation, and then add it to
> each and every container type, duplicating each and every API which defers
> responsibility for construction, when the language gives us a mechanism
> (this one) that works just fine for the purpose?
>
> Note that there's no difference between deferring construction and using
> the proposed std::elide, and constructing the class directly. The class is
> directly constructible from the proposed std::elide because the proposed
> std::elide implicitly converts thereto.
>
> The only issue I have with the paper is the core language addition/change.
> If people want to support std::elide and CTAD there are ways to do that
> which don't involve changing the core language to special case a library
> type.
>
> --Robert
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Tiago Freire via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Thursday, May 30, 2024 15:05
> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>;
> Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> *Cc:* Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden]
> <std-proposals_at_[hidden]>
> *Subject:* Re: [std-proposals] std::elide
>
> The reasons for this class to exist are extremely hacky.
> emplace semantics in std::optional are such that you would be able to pass
> in arguments as you would while instantiating the class itself, and it
> should be anything else.
> Instead of creating a new interface for invocation, it instead tries to
> hijack an existing interface for an rvo hackery which cannot even be done.
> This paper should be killed with fire.
>
> ------------------------------
> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
> of Gašper Ažman via Std-Proposals <std-proposals_at_[hidden]>
> *Sent:* Thursday, May 30, 2024 5:55:27 PM
> *To:* Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> *Cc:* Gašper Ažman <gasper.azman_at_[hidden]>;
> std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> *Subject:* Re: [std-proposals] std::elide
>
> The transparent conversion is useful because I have classes that are
> *only* constructible from an elider - a named one. It's sort of like
> saying that you only have std::in_place_type constructors but you
> didn't care to make them variadic.
>
> A lot of these classes *forward* their construction argument further
> until it gets to where it actually needs to construct an object. This
> matters when you've got expression templates that construct some
> immovable tree of stuff at the end. If I have a component that
> understands std::elide as an elider, but doesn't understand my elider
> as an elider, I can still just construct std::elide from my elider
> directly instead of having to rewrap in a lambda; and vice versa.
>
> The only reason I think having std::elide in the library would be to
> have a common vocabulary type that's better than std::in_place_type +
> variadic forwarding of arguments.
>
> On Thu, May 30, 2024 at 4:35 PM Arthur O'Dwyer
> <arthur.j.odwyer_at_[hidden]> wrote:
> >
> > On Thu, May 30, 2024 at 11:14 AM Frederick Virchanza Gotham via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
> >>
> >> On Thu, May 30, 2024 at 1:26 PM Gašper Ažman wrote:
> >> >
> >> > Both call a function to generate the returned type. Why
> >> > can't an elider *be that function* directly? That way I can
> >> > nest them either way and it still works.
> >>
> >> I have made the following two additions:
> >> template<typename NestedF, typename... NestedParams>
> >> constexpr decltype(auto) operator()(NestedF &&fN,
> NestedParams&&... argsN)
> >> {
> >> return forward<NestedF>(fN)(
> forward<NestedParams>(argsN)... );
> >> }
> >
> >
> > IIUC, this isn't right; what you want here is simply
> > // https://godbolt.org/z/7he9b6GW6
> >
> > constexpr operator R()
> > noexcept(noexcept(apply(static_cast<F_ref>(f),std::move(args_tuple))))
> > {
> > return apply( static_cast<F_ref>(f), std::move(args_tuple) );
> > }
> >
> > constexpr R operator()()
> > noexcept(noexcept(apply(static_cast<F_ref>(f),std::move(args_tuple))))
> > {
> > return *this;
> > }
> >
> > as well as the const-qualified versions of those.
> > The idea, IIUC, is to make the following code work.
> > We suppose that the codebase already has their own `std::elide`-alike —
> which, btw, isn't even a seven-liner; it's now a five-liner.
> >
> > template<class F>
> > struct SCSE {
> > F f_;
> > operator decltype(f_())() const { return f_(); }
> > };
> >
> > Then we have these two calls working already:
> >
> > ocs8.emplace(std::elide([]{ return counting_semaphore<8>(5); }));
> > ocs8.emplace(SCSE([]{ return counting_semaphore<8>(5); }));
> >
> > and Gasper is asking for this call to work as well:
> >
> > ocs8.emplace(SCSE(std::elide([]{ return counting_semaphore<8>(5); })));
> // Gasper's request, IIUC
> >
> > Adding the `operator()` gets us that. Although, I still don't see why
> we want SCSE to be constructible from std::elide. I don't see how this
> helps with "interop." What's a scenario where I'd already have a
> `std::elide` object — whose sole purpose is to be treated like a `T` — and,
> instead of treating it like a `T`, I'm going to try to construct an `SCSE`
> out of it? That seems wrong. An `SCSE` expects a callable `C`, and so my
> `std::elide` should implicitly convert to `C` iff `T=C`, but otherwise it
> should stay aloof, IMHO. I don't see a concrete scenario where I'd want to
> be cavalier about the meaning of `elide` — like, "Please convert to `T` if
> you can, or otherwise convert to `SCSE`." Those are two different "parts of
> speech," IMO.
> >
> > (But, just to be clear, I consider this all academic, because the STL
> should not have `std::elide`.)
> >
> > –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>