Expression switch - an alternate proposal

Stephen Colebourne scolebourne at joda.org
Mon Apr 9 14:31:13 UTC 2018


On 9 April 2018 at 12:49, Remi Forax <forax at univ-mlv.fr> wrote:
> moving to spec-experts as it can interest others.

Replying to amber-dev, as I can't post to amber-spec-experts...

> I am not sure it's that important to make a string distinction between the statement switch and the expression switch.
> You do not give any element or why you think it's important and in my opinion, it's the kind of things that you think is important when you introduce the feature and tend to be less important if the feature was not new.

Its definitely not about making it stand out as being new. There are
differences between the code allowed in a statement switch and that
allowed in an expression switch. Yet the current proposal does not
provide a means to determine what is or is not allowed without looking
all the way up to the switch keyword, potentially off screen.

If there same code were allowed in both, and returning the result was
the only difference

> Basically, your proposal is to use -> eveywhere, i think i prefer the opposite, do not use arrow at all.
> Using arrow in this context is disturbing because it doesn't mean the same things if it's the arrow of the lambda or the arrow inside an expression switch.

I agree that arrow is not ideal (and I've said it publicly before).
But to simplify the point of this proposal I avoided discussing the
arrow now.

> Here is your example with no arrow and no short syntax,
> and now we can discuss about adding a shorter syntax by making break optional if there is one expression.

The syntax test I'm applying is whether it is clear enough from just
the middle of the switch as to what rules apply, ie. whether I can use
return or not, and whether I have to worry about fall through.

My gut is that there needs to be a syntactic device to highlight that
- trying to figure it out just from break expression isn't clear
enough. Just colon doesn't provide quite enough clarity, but it
certainly doesn't have to be arrow.

Stephen


More information about the amber-dev mailing list