Date: Thu, 22 May 2025 19:49:23 +0000
I think it's not productive to talk about a "switch statement with strings" without going into detail regarding the algorithm by which the "magic happens".
switch with numbers have been long understood as "jump tables" because integers are well defined, strictly orderable, uniquely indexable, entities.
Something that strings are not, and it's hard to prove for other types.
For integers, what comparisons take place do not produce visible side effects.
Comparisons for arbitrary types can have visible side effects.
Will a binary search be an acceptable implementation?
Are you limited to just comparing with every single item on the list? Does the order in which comparisons take place matter?
What properties can the compiler deduce about a type such as to be able to deduce an efficient algorithm that is also consistent across different compilers?
IMO the paper proposing the "match" idiom has some issues to explain. Even if it did provide a compiler with an implementation of it (which would have been the bare minimum for it to be successful) it does not mean that this would make behavior across all compilers (which will have a different implementations) the same.
I don't really care so much if you call it "match" or "switch", that is just a way to express the intent for a particular idiom. What I would like to know more is how is this "sausage made", which neither the paper or this mail chain go into enough detail about.
my 2c
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Zhihao Yuan via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, May 22, 2025 8:45:44 PM
To: std-proposals_at_[hidden]cpp.org <std-proposals_at_[hidden]>
Cc: Zhihao Yuan <zy_at_[hidden]>
Subject: Re: [std-proposals] A draft for modern switch
On Thursday, May 22nd, 2025 at 10:53 AM, Nikolay Mihaylov via Std-Proposals <std-proposals_at_[hidden]> wrote:
My 5 cents again :)
I am strongly against modifying switch in this way :)
C++ is C and C++, is not Javascript or PHP where nobody cares about performance.
Wow, if you believe that C++ must care
about performance, then you may want
to consider supporting a switch that
tests strings! What a compiler can do to
optimize a pattern matching that tests
strings but simulates fall-through between
the cases?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
This is exactly why match were proposed.
On Wed, May 21, 2025 at 4:56 PM Jason McKesson via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
On Wed, May 21, 2025 at 3:34 AM Filip via Std-Proposals
<std-proposals_at_[hidden].org<mailto:std-proposals_at_[hidden]>> wrote:
>
> I agree, it seems like a better idea to have switch in non constexpr context available, to act like a nicer option acting like if else.
>
> Maybe I’m missing the key functionality of match, but it looks like a different syntax for something that we already have.
>
> I agree that assignment with match looks like a good idea, why wouldn’t we add that to the switch statement?
Because we're getting pattern matching anyway, which is a superset of
what switch can do. There's no point in improving a legacy feature
when it is simultaneously being rendered obsolete.
> string b = “hello”;
> auto var = switch(b){
> case “hi”: { return 42; }
> case “hello”: { return 43; }
> default: { return 0; } // probably should be mandatory
> };
```
b match {
"hi" => return 42;
"hello" => return 43;
_ => return 0;
}
```
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]g<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
switch with numbers have been long understood as "jump tables" because integers are well defined, strictly orderable, uniquely indexable, entities.
Something that strings are not, and it's hard to prove for other types.
For integers, what comparisons take place do not produce visible side effects.
Comparisons for arbitrary types can have visible side effects.
Will a binary search be an acceptable implementation?
Are you limited to just comparing with every single item on the list? Does the order in which comparisons take place matter?
What properties can the compiler deduce about a type such as to be able to deduce an efficient algorithm that is also consistent across different compilers?
IMO the paper proposing the "match" idiom has some issues to explain. Even if it did provide a compiler with an implementation of it (which would have been the bare minimum for it to be successful) it does not mean that this would make behavior across all compilers (which will have a different implementations) the same.
I don't really care so much if you call it "match" or "switch", that is just a way to express the intent for a particular idiom. What I would like to know more is how is this "sausage made", which neither the paper or this mail chain go into enough detail about.
my 2c
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Zhihao Yuan via Std-Proposals <std-proposals_at_[hidden]>
Sent: Thursday, May 22, 2025 8:45:44 PM
To: std-proposals_at_[hidden]cpp.org <std-proposals_at_[hidden]>
Cc: Zhihao Yuan <zy_at_[hidden]>
Subject: Re: [std-proposals] A draft for modern switch
On Thursday, May 22nd, 2025 at 10:53 AM, Nikolay Mihaylov via Std-Proposals <std-proposals_at_[hidden]> wrote:
My 5 cents again :)
I am strongly against modifying switch in this way :)
C++ is C and C++, is not Javascript or PHP where nobody cares about performance.
Wow, if you believe that C++ must care
about performance, then you may want
to consider supporting a switch that
tests strings! What a compiler can do to
optimize a pattern matching that tests
strings but simulates fall-through between
the cases?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________
This is exactly why match were proposed.
On Wed, May 21, 2025 at 4:56 PM Jason McKesson via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
On Wed, May 21, 2025 at 3:34 AM Filip via Std-Proposals
<std-proposals_at_[hidden].org<mailto:std-proposals_at_[hidden]>> wrote:
>
> I agree, it seems like a better idea to have switch in non constexpr context available, to act like a nicer option acting like if else.
>
> Maybe I’m missing the key functionality of match, but it looks like a different syntax for something that we already have.
>
> I agree that assignment with match looks like a good idea, why wouldn’t we add that to the switch statement?
Because we're getting pattern matching anyway, which is a superset of
what switch can do. There's no point in improving a legacy feature
when it is simultaneously being rendered obsolete.
> string b = “hello”;
> auto var = switch(b){
> case “hi”: { return 42; }
> case “hello”: { return 43; }
> default: { return 0; } // probably should be mandatory
> };
```
b match {
"hi" => return 42;
"hello" => return 43;
_ => return 0;
}
```
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]g<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-05-22 19:49:29