This looks like an excessive amount of special pleading for a feature with dubious usage.

You may not realize it but the alternative "emplace_invoke" is pretty much a nail in the coffin of std::elide.

Special concessions are unnecessary.

-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Frederick Virchanza Gotham via Std-Proposals
Sent: Wednesday, May 29, 2024 23:32
To: std-proposals_at_lists.isocpp.org
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_gmail.com>
Subject: Re: [std-proposals] How should we tag a class? Use an empty base class or a typedef?

On Wed, May 29, 2024 at 2:58 PM Arthur O'Dwyer wrote:
>
> Frederick's proposed solution (which, as I said, IMO is very bad) is
> that template type deduction should never deduce a (possibly
> cvref-qualified) specialization of `elide`.


What if we were to make it more generic, and not make it specifically about std::elide?

What I mean is, instead of naming the tag "tag_elide", we call it "tag_no_sole_param_constructor", so that in the future it can be used to implement other new ideas.

Or if that doesn't sound appetising. . . here's another idea:

Similar to how deduction guides come after a class definition, what if we could specify "template instantiation failure guides" for a class?
So you would write your class:

    template<typename F, typename... Params>
    class elide { . . . };

And then after the class definition, you would write a "template instantiation failure guide" something like as follows:

    template< typename C, typename T> requires std::is_specialization_v< std::remove_cvref_t<T>, std::elide >
    C::C(T&&) = false;

The above guide disallows the instantiation of any constructor which takes exactly one parameter which is a specialisation of std::elide.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals