It's a valid consideration, Bjorn, but I think a new name is more
useful - elide must be explicitly handled in deduction guides, so
reusing an existing "curried" thing creates possibly unwanted
ambiguities.

for instance, I'd expect std::optional to gain a deduction guide of

template <typename F>
optional(std::elide<F>&&) -> optional<std::elide<F>::result_type>;

so that one could directly do `return optional{elide{my-ctor-function}};`

On Fri, May 31, 2024 at 1:34 PM Bjorn Reese via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> On 5/31/24 11:24, Gašper Ažman via Std-Proposals wrote:
> > My "elide", as exists in my codebase:
> >
> > template <typename F>
> > struct init_t {
> > F f;
> > using result_t = decltype(std::move(std::declval<F>())());
> > static constexpr bool is_noexcept = noexcept(std::move(std::declval<F>())());
> > constexpr operator result_t () &&
> > noexcept(is_noexcept) {
> > return std::move(f)();
> > }
> > constexpr result_t operator()() &&
> > noexcept(is_noexcept) {
> > return std::move(f)();
> > }
> > };
> > template <typename F>
> > init_t(F&&) -> init_t<std::remove_cvref_t<F>>;
>
> So
>
> elide(fn, args...)
>
> would be equivalent to
>
> init_t(bind_front(fn, args...))
>
> Which raises the question: if we want a facility that contextually
> converts to the return type, should we add the conversion operator to
> bind_front (and bind and bind_back) instead of introducing a new type?
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals