JEP325: Switch expressions spec

[Guy Steele]

> On Apr 20, 2018, at 1:37 PM, Kevin Bourrillion <kevinb at google.com> wrote:
> 
> On Wed, Apr 18, 2018 at 11:16 AM, Kevin Bourrillion <kevinb at google.com <mailto:kevinb at google.com>> wrote:
> 
> If one of the patterns is a constant expression or enum constant that is equal to the value of the selector expression, then we say that the patternmatches.
> 
> I think "equal" is ambiguous for strings (and will be for doubles when they happen).
> 
> Whoops: I belatedly noticed that we are expanding to all primitive types already. Okay. So, unless I missed it somewhere, I think we need to specify that all comparisons are made as if by equals() on the (boxed) type (or whatever better way to word it). We might even want to call out the specific consequences that case NaN: works as expected, and that 0.0 and -0.0 are fully distinct despite being ==.
> 
> But here is the real wrench I want to throw in the works... (and I apologize, as always, if I am unknowingly rehashing old decisions that were already finalized):
> 
> The most compelling reason to support float and double switches is the fact that pattern matching will automatically cover them via boxing anyway. If it were not for that, I believe it is a feature with too much risk to be useful. case 0.1: simply does not mean what any developer would wish it to mean. At Google we spend real effort trying to get our developers to depend less on exact floating-point equality, not more.

I agree that it would (almost always) be insane to write `case 0.1:`.

However, it may actually be extremely attractive for some purposes to write something like:

    switch (x) {
        case NaN -> foo;
        case Double.NEGATIVE_INFINITY -> bar;
        case Double.POSITIVE_INFINITY -> baz;
        case +0.0 -> quux;
        case -0.0 -> ztesch;
        default -> frobboz(x);
    }

and I can even imagine `case 1.0 ->` or `case 2.0 ->` sneaking in as special cases on occasion.

You don’t always want to write library code this way—rather, analysis may show that `frobboz` computes the desired results for some or all of the special cases.  But when code clarity is more important than that last ounce of speed, this is a very clear way to say what you want.

Seems to me that the compiler could certainly warn about case labels such as 0.1 that suffer rounding during the decimal-to-binary conversion.  Or about any category of cases label we wish to denigrate.

—Guy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180420/28fe7c72/attachment.html>