Re: else ladders practice

On 04/11/2024 20:50, Bart wrote:

On 04/11/2024 16:35, David Brown wrote:

On 03/11/2024 21:00, Bart wrote:

 

To my mind, this is a type of "multi-way selection" :
>
     (const int []){ a, b, c }[n];
>
I can't see any good reason to exclude it as fitting the descriptive phrase.

 

And if "a", "b" and "c" are not constant, but require evaluation of some sort, it does not change things.  Of course if these required significant effort to evaluate,

 Or you had a hundred of them.
 

or had side-effects, then you would most likely want a "multi-way selection" construction that did the selection first, then the evaluation - but that's a matter of programmer choice, and does not change the terms.

  You still don't get how different the concepts are.

Yes, I do.  I also understand how they are sometimes exactly the same thing, depending on the language, and how they can often have the same end result, depending on the details, and how they can often be different, especially in the face of side-effects or efficiency concerns.
Look, it's really /very/ simple.
A) You can have a construct that says "choose one of these N things to execute and evaluate, and return that value (if any)".
B) You can have a construct that says "here are N things, select one of them to return as a value".
Both of these can reasonably be called "multi-way selection" constructs.   Some languages can have one as a common construct, other languages may have the other, and many support both in some way.  Pretty much any language that allows the programmer to have control over execution order will let you do both in some way, even if there is not a clear language construct for it and you have to write it manually in code.
Mostly type A will be most efficient if there is a lot of effort involved in putting together the things to select.  Type B is likely to be most efficient if you already have the collection of things to choose from (it can be as simple as an array lookup), if the creation of the collection can be done in parallel (such as in some SIMD uses), or if the cpu can generate them all before it has established the selection index.
Sometimes type A will be the simplest and clearest in the code, sometimes type B will be the simplest and clearest in the code.
Both of these constructs are "multi-way selections".
Your mistake is in thinking that type A is all there is and all that matters, possibly because you feel you have a better implementation for it than C has.  (I think that you /do/ have a nicer switch than C, but that does not justify limiting your thinking to it.)