I’d like to propose a slightly different perspective. In some fields, such as Embedded, people use C and C++ together often and hence rely on seamless compatibility as much as possible. switch is a C construct. Changing it in C++ can cause confusion but likely more serious issues. Generally speaking, if any C construct is to change, it is more appropriate for the proposal to go through WG 14 and be standardized in C first rather than doing it backwards.

Honestly, I doubt WG 14 will approve such a change, so there is no point in pushing it as a C++ proposal.

> On May 27, 2025, at 12:18, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> This has been the core of my criticism.
> 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_at_[hidden]> on behalf of Fabio Alemagna via Std-Proposals <std-proposals_at_[hidden]>
> Sent: Tuesday, May 27, 2025 5:19:18 PM
> To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
> Cc: Fabio Alemagna <falemagn_at_[hidden]>
> 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_at_[hidden] <mailto:std-proposals_at_[hidden]>> 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_at_[hidden] <mailto:std-proposals_at_[hidden]>> 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 <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
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals