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.
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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals