Re: else ladders practice

On 01/11/2024 18:47, David Brown wrote:

On 01/11/2024 19:05, Bart wrote:

On 01/11/2024 17:35, David Brown wrote:

>
What you have written here is all correct, but a more common method would be to avoid having three printf's :
>
void shout_a_number(int n) {
     printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
}
>
That's more likely to match what people would want.

>
I was also trying to show that all elements are evaluated, so each has to have some side-effect to illustrate that.

 Fair enough.
 

>
A true N-way-select construct (C only really has ?:) would evaluate only one, and would deal with an out-of-range condition.

 That's a matter of opinion and design choice, rather than being requirements for a "true" select construct.

I don't think it's just opinion.
In general, an if-else-if chain (which was the point of the OP), would evaluate only one branch. So would a switch-case construct if sensibly implemented (in C's version, anything goes).
The same applies to C's c?a:b operator: only one of a or b is evaluated, not both.
(This also why implementing if, switch, ?: via functions, which lots are keen to do in the reddit PL forum, requires closures, lazy evaluation or other advanced features.)

  You are free to choose the rules you want for your own language, but you are not free to dictate what you think the rules should be for others.  (You are welcome to /opinions/, of course.)
 

>
(In my implementations, a default/else branch value must be provided if the whole thing is expected to return a value.)
>

 OK, if that's what you want.  My preference, if I were putting together what /I/ thought was an idea language for /my/ use, would be heavy use of explicit specifications and contracts for code, so that a default/else branch is either disallowed (if there the selection covers all legal values) or required (if the selection is abbreviated).  A default value "just in case" is, IMHO, worse than useless.

All such multiway constructs in my languages (there are 4, one of which the job of both 'if' and  C's ?:) have an optional else branch. A missing 'else' has an notional 'void' type.
But it becomes mandatory if the whole thing returns a value, to satisfy the type system, because otherwise it will try and match with 'void'.
SOMETHING needs to happen when none of the branches are executed; what value would be returned then? The behaviour needs to be defined. You don't want to rely on compiler analysis for this stuff.
In C on the other hand, the ':' of '?:' is always needed, even when it is not expected to yield a value. Hence you often see this things like this:
    p == NULL ? puts("error"): 0;
Here, gcc at least, also requires the types of the two branches to match, even though the whole construct yields no common value. Meanwhile I allow this (if I was keen on a compact form):
   (p = nil | print "error")
No else is needed.