Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Subject: Re: New syntax explosion
To: dev@groovy.apache.org
References: <2BA8478A2FBAFF4FBFDF1724FAD8C09E8C817AFE@C111BKGPMBX48.ERF.thomson.com>
 <CAO_wNoc0MBhX1=fKv6P7up-xMT5S9hyn8jzzKVQSu5a7DZaiMQ@mail.gmail.com>
 <CAAsy7bGVOoPfwuzRktengqgSD9ChVk01MC=L7OP3WHB4_nj_gA@mail.gmail.com>
From: Jochen Theodorou <blackdrag@gmx.org>
Message-ID: <960ed1af-4a03-fc96-c40a-1b5976a619c9@gmx.org>
Date: Fri, 6 Oct 2017 01:01:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAAsy7bGVOoPfwuzRktengqgSD9ChVk01MC=L7OP3WHB4_nj_gA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
archived-at: Thu, 05 Oct 2017 23:02:03 -0000

On 05.10.2017 21:23, Andres Almiray wrote:
> FYI the switch statement is likely to become an expression in Java.next 
> (18.3 or 18.9) thus Groovy will have to support it at some point.

To give here a bit more fuel see JEP 305 and 
http://cr.openjdk.java.net/%7Ebriangoetz/amber/

I take from this, that the syntax is most likely not going to be the 
statement as expression. And in my opinion that does not make sense, 
just because it can return something does not make it an proper 
expression right away. After all we have the return statement, and it 
does return something, but it is no expression and nobody here would 
think about making it one.

In those documents they are even giving up on something like this:

switch (someNumber) {
   case 1:
   case 2:
     return "some number";
     break;
   default:
     return "unexpected number";
}

no break anymore, case 1 and case 2 cannot match at the same time. And 
now you have to have blocks for more than one line:

return switch (someNumber) {
   case 1 || 2 -> "some number"
   default -> { return "unexpected number" }
}

And since this is derived from the lambda constructs, it is clear I have 
a lambda body on the right, thus a return will return from the lambda, 
not the method I am in and then something like just return "some number" 
could be even illegal.

And since this will mean "abusing" switch-case for very different 
semantics I don´t really expect this to be the final form, if the cases 
should support more complex expressions and destructering patterns.

And now compare with the Groovy version:

return switch (someNumber) {
   case 1:
   case 2:
     return "some number"
   default:
     return "unexpected number"
}

or without the internal returns:

return switch (someNumber) {
   case 1:
   case 2:
     "some number"
     break;
   default:
     "unexpected number"
}

Frankly I am unsure what I really prefer.

If we really want to just implement what java has, we have to wait till 
they finalize the syntax. If we want to go beyond that, we have again to 
wait. or we get again similar but different versions of syntax and 
semantic for a large number of cases as we have now with Closure and 
lambdas.

And btw, we should probably mention Scala here. look at their 
match-case. I think 
https://www.artima.com/pins1ed/case-classes-and-pattern-matching.html 
gives here an interesting overview. I am not saying we should do what 
Scala did here, but compare what is on this page with the documents from 
Brian. And you will find many many parallels and also maybe where we 
will go to. Maybe not with Case-classes like in Scala, but if 
destructering comes, then there will be bigger changes...

Anyway I think I start to loop here, so I better stop ;)

bye Jochen