New JEP: Switch Expressions for the Java Language

[Ali Ebrahimi]

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