Call for bikeshed -- break replacement in expression switch

[Guy Steele]

> On May 13, 2019, at 10:28 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> 
> 
> Having lost (nearly) this argument years ago, I'm not sure why I bother, but ...
> 
> On 5/12/19 3:38 PM, Brian Goetz wrote:
>> 
>> Looking at what other languages have done here, there are a few broad directions: 
>> 
>>  - A statement like “break-with v”, indicating that the enclosing structured expression is completing normally with the provided value.  
>>  - An operator that serves the same purpose, such as “-> e”.
>>  - Assigning to some magic variable (this is how Pascal indicates the return value of a function).  
>>  - Treating the last expression in the block as the result.  
> 
> (The last one being "progn", the earliest and arguably still best of these.)
> 
>> 
>> I think we can dispatch all but the first relatively easily: ...
>> 
>> 
>>  - Everywhere else in the language (such as method bodies), you are free to yield up a value from the middle of the block, perhaps from within a control construct like a loop; restricting the RHS of case blocks to put their result last would be a significant new restriction, and would limit the ability to refactor to/from methods. And further, the convention of putting the result last, while a fine one for a language that is “expressions all the way down”, would likely be too subtle a cue in Java.  
> 
> Last time around, the last point about subtlety and odd-lookingness of progn seemed to bother people the most.  It is possible to make it  less subtle by additionally requiring some symbol. Prefix "^" is still available. Allowing for example:
> 
> 
>     String s = (foo != null) 
>         ? s
>         : { println(“null again at line” + __LINE__);  ^ “null”;  };
> 
> Which still lgtm….

Could be worse, but looks to be like Java with a Smalltalk accent—just as

	{ foo(); bar }

is Java with a Lisp (or ECL) accent.  I would prefer to adapt a bit of syntax from ECL: the statement

	b => e;

evaluates b as a boolean expression, and if it is true, then e is evaluated and its value becomes the value of the block.  This gives you a syntax very similar to that of Lisp COND:

	{ x > y => 1; x < y => -1; true => 0; }

If you then want to further abbreviate “true =>”, well, that’s another story, but I wouldn’t blame you.

—Guy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190513/554b4432/attachment-0001.html>