New JEP: Switch Expressions for the Java Language

[Brian Goetz]

A request please, folks: if you're going to reply to the observers list, 
please don't copy the individual EG members directly.  It should be 
their choice whether they are involved in -observers discussions or not.

On this particular message: let's figure out the right semantics before 
we redesign the syntax.  (FYI: both of these syntax options were already 
considered.)

On 12/11/2017 1:17 AM, Ali Ebrahimi wrote:
> Hi,
>
>     >
>     > Your talking about semantics consistency in general, it's not
>     what a regular user see, the "syntax to semantics" consistency is
>     more important,
>     > if the syntax use an arrow, then the semantics should be the
>     same with the other(s) construct(s) that are using an arrow.
>
>     This is a good general principle, and among other things it means
>     we should choose a syntax that is evocative of what we want to
>     mean (which we’re not fully decided on yet).  If what we mean is
>     “anything goes”, then maybe what we should conclude is that -> is
>     a bad choice.  (We certainly have “justified” the uncomfortable
>     ambiguity between local and nonlocal return by comparison with
>     lambdas).  I think all such choices are provisional until we’ve
>     worked out both what we want to have happen, and a sensible way to
>     express it, and then ask ourselves if we’re asking too much (both
>     semantically and syntactically) of users.  But lets not let the
>     tail wag the dog.
>
> I agree that "syntax to semantics" consistency should be preserved and 
> this was my point in my previous post (may be I was not clear enough).
> But my point:
>
>   * expression switches is more similar to statement switches than lambdas
>
> So getting closer that to lambdas unnecessarily make language more 
> complex. The switch construct (expression/statement) unlike lambdas is 
> a inlined language construct and don't have standalone scope so 
> returning from this construct propagates to outer/enclosing 
> construct(for example method) and changing this old rule surprise java 
> users.
>
> ُ
>
>     So, speaking semantically only:
>      - We should not allow fall through in expression switch; I don’t
>     think it makes any sense.
>      - I’m pretty convinced that nonlocal returns out of expression
>     switch (other than throwing) is similarly a wrong fit.  (We allow
>     this in neither conditional expressions nor lambdas.)
>      - Switch expressions should definitely be able to reference
>     locals, but we’re open minded to some restrictions (such as no
>     mutation).
>      - We could justify allowing switch expressions to mutate locals,
>     since other expressions can too, but we could similarly justify
>     restricting mutation
>      - More strongly, we could justify restricting even referencing
>     non-eff-final locals, though this is starting to get onto thin
>     ice, because the only argument we have for this is “for
>     (superficial) consistency with lambdas”, which is pretty weak.
>
>     > and there are several arguments against 2, as you wrote, "it's
>     unlike anything else", it forces users to think where the capture
>     occurs exactly (my example above) and it's not "syntax to
>     semantics" consistent but this can be fixed by not using the arrow
>     symbol.
>
>     If mutation is restricted (which I think is really the first
>     question), then there’s no confusion about "where the capture
>     happens”.  So perhaps we should examine the basis on which we are
>     willing to justify restricting mutation.
>
> The minimal differences we need for expression switches wrt statement 
> switches:
>
>   *   Don't allow fall through in expression switch (break by default):
>
>  compiler implicitly inserts break stats.
>
>   *   Give back value from right hand side picked case clause
>
> But how: Since I disagree with using 'return' for this purpose we have 
> some options as :
> 1) *Block expression: *
> *The type of the block expression is the type of the last expression 
> it encloses*
> |Foo f = switch (kind) { case EMPTY : new Foo(); case SINGLETON : { Foo 
> x = new Foo(); x.add(ONE); x; } case MANY : { 
> System.out.println("Debugging statement!"); ... } }|
> 2) *Break by value*
> |Foo f = switch (kind) { case EMPTY : new Foo(); //or |||||*break *||||*|new Foo();|*| case SINGLETON : { Foo x = new Foo(); x.add(ONE); *b*||*reak *x; } case MANY : { System.out.println("Debugging statement!"); ||*break *... } }|
> I deliberately not used arrow syntax here to see whether we need it or 
> not.
> May be we have other options.......
>
> -- 
>
> Best Regards,
> Ali Ebrahimi