Switch expressions spec

[Leonid Arbuzov]

Hi Alex,

There are negative tests with missed result expressions:

         int a = switch (selectorExpr) {
             case 0 -> 1;
             case 1 -> 1;
             default -> ;
         };

         int a = switch (selectorExpr) {
             case 0 -> { break 1; }
             case 1 -> { break 1; }
             default -> { fun(); }
         };

If you meant no result expressions at all then I couldn't find such test yet.
It can be added in JCK13.

Thanks,
Leonid

On 3/19/2019 5:28 PM, Alex Buckley wrote:
> Hi Leonid,
>
> So there are no negative tests that check what happens if a switch 
> expression has no result expressions?
>
> Alex
>
> On 3/19/2019 5:24 PM, leonid.arbouzov at oracle.com wrote:
>> There are tests on switch expression with cases that throwing exception,
>> causing division by zero, index out of range, etc.
>> These are all positive tests i.e. compile fine.
>>
>> Thanks,
>> Leonid
>>
>>
>> On 3/15/19 1:20 PM, Alex Buckley wrote:
>>> OK, we intend at least one result expression to be required, so the
>>> spec is correct as is.
>>>
>>> (I should have been clearer that my belief was about the intent of the
>>> spec, rather than about how I personally think completion should 
>>> occur.)
>>>
>>> Manoj didn't say what javac build he is testing with, but this is a
>>> substantial discrepancy between compiler and spec. I hope that Leonid
>>> Arbouzov (cc'd) can tell us what conformance tests exist in this area.
>>>
>>> Alex
>>>
>>> On 3/15/2019 12:09 PM, Brian Goetz wrote:
>>>> At the same time, we also reaffirmed our choice to _not_ allow throw
>>>> from one half of a conditional:
>>>>
>>>>      int x = foo ? 3 : throw new FooException()
>>>>
>>>> But John has this right — the high order bit is that every expression
>>>> should have a defined normal completion, and a type, even if
>>>> computing sub-expressions (or in this case, sub-statements) might
>>>> throw.  And without at least one arm yielding a value, it would be
>>>> impossible to infer the type of the expression.
>>>>
>>>>> On Mar 15, 2019, at 3:01 PM, John Rose <john.r.rose at oracle.com> 
>>>>> wrote:
>>>>>
>>>>> On Mar 15, 2019, at 11:39 AM, Alex Buckley <alex.buckley at oracle.com>
>>>>> wrote:
>>>>>>
>>>>>> In a switch expression, I believe it should be legal for every
>>>>>> `case`/`default` arm to complete abruptly _for a reason other than
>>>>>> a break with value_.
>>>>>
>>>>> My reading of Gavin's draft is that he is doing something very
>>>>> subtle there, which is to retain an existing feature in the language
>>>>> that an expression always has a defined normal completion.
>>>>>
>>>>> We also don't have expressions of the form "throw e". Allowing
>>>>> a switch expression to complete without a value on *every* arm
>>>>> raises the same question as "throw e" as an expression. How do
>>>>> you type "f(throw e)"?  If you can answer that, then you can also
>>>>> have switch expressions that refuse to break with any values.
>>>>>
>>>>> BTW, if an expression has a defined normal completion, it also
>>>>> has a possible type.  By possible type I mean at least one correct
>>>>> typing (poly-expressions can have many).  So one obvious
>>>>> result of Gavin's draft is that you derive possible types from
>>>>> the arms of the switch expression that break with values.
>>>>>
>>>>> But the root requirement, I think, is to preserve the possible
>>>>> normal normal of every expression.
>>>>>
>>>>> "What about some form of 1/0?"  That's a good question.
>>>>> What about it?  It completes normally with a type of int.
>>>>> Dynamically, the normal completion is never taken.
>>>>> Gavin might call that a "notional normal completion"
>>>>> (I like that word) provided to uphold the general principle
>>>>> even where static analysis proves that the Turing machine
>>>>> fails to return normally.
>>>>>
>>>>> — John
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190320/82b1a6cd/attachment.html>