Feedback wanted: switch expression typing

[Doug Lea]

On Sat, March 31, 2018 6:23 am, forax at univ-mlv.fr wrote:
> The fact that the semantics of ?: is very ad-hoc is a kind of accident of
> the history,
> we may want to fix it but i do not see why we have to fix it at the same
> time that we introduce the expression switch,
> we can fix the semantics of ?: later or never.

Where "later" probably means "never". It should be fixed now.
I agree that (B) and (C) are basically the same, so choose (C).
I've had to fiddle with :? to get the compiler to shut up about
reasonable-looking expressions. (Sorry, I can't recall examples.)
Having the same story for both of them would be best, assuming
that existing code doesn't break.

-Doug

>
> Rémi
>
> ----- Mail original -----
>> De: "daniel smith" <daniel.smith at oracle.com>
>> À: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
>> Envoyé: Samedi 31 Mars 2018 03:44:49
>> Objet: Re: Feedback wanted: switch expression typing
>
>>> On Mar 30, 2018, at 10:54 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>> I do not see (B) as sacrifying the consistency because the premise is
>>> that an
>>> expression switch should be consistent with ?:
>>>
>>> But an expression switch can also be modeled as a classical switch that
>>> returns
>>> it's value to a local variable.
>>>
>>>  int a = switch(foo) {
>>>    case 'a' -> 2;
>>>    case 'b' -> 3;
>>>  }
>>> can be see as
>>>  int a = $switch(foo);
>>> with
>>>  int $switch(char foo) {
>>>    case 'a': return 2;
>>>    case 'b': return 3;
>>>  }
>>
>> I mean, sure, this is another way to assert "switches in assignment
>> contexts
>> should always be poly expressions".
>>
>> But it's just as easy to assert "conditional expressions in assignment
>> contexts
>> should always be poly expressions".
>>
>> int a = test ? 2 : 3;
>> can be seen as
>> int a = $conditional(test);
>> with
>> int $conditional(boolean test) {
>>    if (test) return 2;
>>    else return 3;
>> }
>>
>> Those are probably good principles. But if we embrace them, we're doing
>> (C).
>>
>> —Dan
>