I didn't have that idea and I'm against it.

I don't think we should special case std::elide in the core language in any way. Not just on principle but because I don't think there's a one size fits all rule that can "fix" these "problems."

I explicitly want std::elide or its equivalent to interact with CTAD. I explicitly want std::elide to be deduced as a template parameter to constructors (unary or otherwise). These are both things that I actually do in code I have deployed on production systems right now.

--Robert

________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, June 4, 2024 12:24
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] std::elide

On Tue, Jun 4, 2024 at 5:02 PM Robert A.H. Leahy wrote:
>
> If you prevent Hasher from hashing the elider what does
> that mean for classes that do want to accept elide objects
> as constructor arguments?


Robert you had the idea of forbidding only the CTAD, so that the
following would fail:

    Hasher myhasher( myelider );

but the following would succeed when you spell out the template
parameter type explicitly:

    Hasher< elide<Hasher(void)> > myhasher( myelider );

This might be a good solution.


> I don't think making poorly-designed classes work is a
> problem worth solving. Those classes should be updated/redesigned.


But these classes have only been determined to be "poorly-designed"
after we've invented our fancy new feature "std::elide". Prior to the
invention of "std::elide", these classes weren't poorly designed. We
can't just introduce a new feature and be like, "You're in Texas now
kid".

So we have two options:
    (1) Tell everyone, "Tough luck, you need to change your class"
    (2) Make a core language change so that they don't need to change
their class

I think it should be No. 2. But the debate goes on as to what this
core language change should be.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]g
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals