If you prevent Hasher from hashing the elider what does that mean for classes that do want to accept elide objects as constructor arguments?

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

--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 11:20
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]m>
Subject: Re: [std-proposals] std::elide

On Tue, Jun 4, 2024 at 3:14 PM Robert wrote:
>>
>> Tiago wrote:
>>
>> I think you misunderstand the problem.
>>
>> The problem was with templated constructors
>> of a class, not with the constructor of a templated class.
>
> That's also not a problem.
>
> Constrain your templated constructors properly, if you don't
> that's a design problem, not a problem with the language standard.


Before I begin, it isn't optimal to use "std::optional" and
"std::variant" as example classes in this discussion, because we're
able to change them while we're changing other parts of the Standard.

So let's use "boost::static_vector" as an example instead. Let's say
that we're not allowed to edit the header file
"boost/container/static_vector.hpp", but we still want to be able to
use it with "std::elide". I just found out today that you can use
Boost up on GodBolt so I'm giddy as a schoolgirl right now, but anyway
the following godbolt shows the problem:

    https://godbolt.org/z/vGq8drMPs

In the above godbolt, the class Hasher, has an accept-all constructor
because it should be able to get the MD5 hash of anything you give it.
But when we try to use "std::elide" with it, the Hasher hashes the
elider object instead of hashing the four numbers found inside
"FunctionReturnsHasher".

So we need to prevent the Hasher class's constructor from having
'std::elide' as its parameter type, which we can do as follows:

    https://godbolt.org/z/e597a979W

All I did was apply a constraint to Hasher's constructor as follows:
   requires (!(std::derived_from<Params,elide_base> || ...))

But now here's the problem, we simultaneously want:
    (1) To prevent the Hasher from hashing the elider
    (2) To not have to edit the class definition of Hasher

This is why we're talking about having some sort of change to the core
language that will prevent the Hasher from hashing the elider. And
please . . . pretty please . . . . . . for the love of your high power
(to those who have a higher power), don't miss the woods for the trees
here and write reason after reason after reason why my Hasher class
isn't the best thing since sliced bread. It's an example.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals