> On Apr 20, 2018, at 1:37 PM, Kevin Bourrillion <kev...@google.com> wrote:
>
> On Wed, Apr 18, 2018 at 11:16 AM, Kevin Bourrillion <kev...@google.com
> <mailto:kev...@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
