RFR: JDK-8192963/JDK-8206986 JEP 325: Switch Expressions (Preview)

[Maurizio Cimadamore]

On 28/08/18 14:50, Jan Lahoda wrote:
> On 28.8.2018 15:05, Maurizio Cimadamore wrote:
>>
>>
>> On 28/08/18 13:41, Jan Lahoda wrote:
>>> It would be nicer if the second error didn't occur, but not sure how
>>> to do that. It would be easy to change the classification in this case
>>> to lambda, the error would then be:
>>> ---
>>> SwitchArrowBrokenConstant.java:13: error: : or -> expected
>>>             case (a, b) -> {}
>>>                              ^
>>> ---
>>>
>>> (Only this single error.) But it seems it might suggest it is OK to
>>> continue from here with ':' or '->', while it is not OK. So I incline
>>> more to the variant which starts with "')' expected", even if there's
>>> a second error that's not very nice.
>> If classification is changed to lambda, then can't we add some check in
>> the lambda parsing code so that if the 'lambda allowed' mode is not set,
>> an error of the kind:
>>
>> 'lambda not expected here'
>>
>> is generated?
>
> Yes, that'd be doable I think:
> http://cr.openjdk.java.net/~jlahoda/8192963/webrev.classify.as.lambda/
>
> Which would produce:
> SwitchArrowBrokenConstant.java:13: error: lambda expression not 
> expected here
>             case (a, b) -> {}
>                         ^
> SwitchArrowBrokenConstant.java:13: error: : or -> expected
>             case (a, b) -> {}
>                              ^
>
> But it is not clear if the user intended to write a lambda expression 
> here, or if the intent was to write a "deconstruction pattern"?
Well, in my view, the user happened to write a perfectly valid lambda 
expression where a constant expression was expected. So, if it were me, 
I'd drop the last error about '->' or ':' expected and just focus on the 
lambda popping up on an unexpected place.

Maurizio
>
> Thanks,
>     Jan
>
>>
>> Maurizio