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

[Maurizio Cimadamore]

On 28/08/18 15:10, Maurizio Cimadamore wrote:
>
>
> 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.
In any case, just to be clear - your latest webrev is fine - I think 
we're discussing on very minor error recovery details and I see no need 
to hold back the code because of this. We can file followup issues for 
these kind of bugs, and re-evaluate as we gather more feedback?

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