Regardless of either you want to call it "match" or "switch" it doesn't matter. There's also no requirement that switch much operate in O(1) as opposed O(logN) (which is more likely the case in practice).

The problem is, you have a set of strings, or some other type with different orderability properties. How does the core language figures out how to order the elements? What is the best algorithm that you can just generate in order to ensure a match?

How would it know that hashing would be an acceptable solution? Would it be possible to just look at the first character of the string and transform it into a regular switch (and be more efficient depending on the set of cases)? Could you even construct a binary decision tree that ensures that the right case is found?

Without this, this proposal is an exercise in futility.

From: Std-Proposals <std-proposals-bounces@lists.isocpp.org> on behalf of Fabio Alemagna via Std-Proposals <std-proposals@lists.isocpp.org>
Sent: Tuesday, May 27, 2025 5:19:18 PM
To: std-proposals@lists.isocpp.org <std-proposals@lists.isocpp.org>
Cc: Fabio Alemagna <falemagn@gmail.com>
Subject: Re: [std-proposals] A draft for modern switch

Il giorno mar 27 mag 2025 alle ore 16:47 Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> ha scritto:

On Tuesday, 27 May 2025 10:32:13 Brasilia Standard Time Fabio Alemagna via
Std-Proposals wrote:
> Il giorno mar 27 mag 2025 alle ore 15:23 Thiago Macieira via Std-Proposals <
> std-proposals@lists.isocpp.org> ha scritto:
> > [...] An equality operator
> > alone won't suffice, because then the order of case labels would matter,
> > which
> > seems ill-advised to me.
>
> Why would the order matter? You're looking for an item in a unordered set.
> Of course, having other operators or even a hash function defined for the
> specific type would make it possible to optimize the search.

Because, with user types and weak ordering, two different entries in the case
list could be equivalent to the sought item. That is, we could have A equiv. B
and A equiv. C. Should the compiler require that therefore B equiv. C? Would
it need to enforce that by performing the O(n²) checks at compile time, or
would that just be declared UB or EB?

If the set is small, O(n²) might be acceptable, but performance would of course improve by making the set ordered, or by implementing a hash function for the type.

It's also plausible to me to make the order of case labels matter. It really depends on the use case and the acceptable trade-off.

> As I've mentioned earlier, there's a library implementation of this. It can
> of course be made better, but the core functionality is there. Have a look:
> https://github.com/falemagn/uberswitch

The fact that library implementations exist should indicate a core language
construct isn't necessary.

That was actually my whole point. I'd explore the possibility to improve on that library solution before attempting to extend the language with another version of switch that overlaps with the pattern matching functionality.

Fabio