Switching on float/double/long
Brian Goetz
brian.goetz at oracle.com
Fri Dec 15 20:55:48 UTC 2017
Yes, that's right.
However, we can still place restrictions on _switch_ if we felt they
were warranted. For example, we could prohibit switch from taking
arguments whose static type is float/Float, if we wanted to, or restrict
constant `case` labels from having floating point patterns, without
restricting nested matches (e.g., Complex(var re, 0.0d)). Not saying
that's a good idea, but we could do so without pulling the rug out from
under the pattern matching tower. (We play a related game with nulls.)
One restriction I think we should place (I've written about this before)
is that we should restrict type-polymorphic numeric constant patterns
and primitive type-test patterns in all pattern-matching contexts,
except where they are type-restating. So these are OK:
switch (anInt) {
case 0: ...
case int x
where x < 0: ...
}
switch (anInteger) {
case 0: ...
case int x
where x < 0: ...
}
switch (aFloat) {
case 0.0f: ...
case float f
where f < 0.0f: ...
}
But I think we should restrict this:
switch (anObject) {
case 0: ...
case int x: ...
}
This is because of the ambiguity that "Object 0" could be Integer 0,
Long 0, Short 0, etc. If you mean `Integer`, say `Integer` here.
On 12/15/2017 3:44 PM, Kevin Bourrillion wrote:
> On Fri, Dec 15, 2017 at 11:58 AM, Dan Smith <daniel.smith at oracle.com
> <mailto:daniel.smith at oracle.com>> wrote:
>
> > On Dec 13, 2017, at 5:51 PM, John Rose <john.r.rose at oracle.com <mailto:john.r.rose at oracle.com>> wrote:
> >
> > But we only get to set the default once. So perhaps we should delay
> > supporting floats directly, until we can put all three or four float
> > matching predicates in front of us and decide which is the default.
>
> > On Dec 14, 2017, at 9:09 AM, Kevin Bourrillion <kevinb at google.com <mailto:kevinb at google.com>>
> wrote:
> >
> > Switch on long: sure.
> >
> > Switch on float/double: why?
>
> When you guys say you'd like to _not_ support floating-points, I'm
> not sure what you mean.
>
> The input to a switch can have any type, including Object.
>
>
> If this much is given, then yes, of course we should allow `switch
> (primitiveDouble)`. I was trying to connect the dots before and I
> think I've got them now. My /current/ limited understanding is that
> (a) it makes a lot of sense for the pattern-matching feature to use
> the existing switch construct, and (b) it follows inescapably from
> that that `switch (somePrimitiveDouble)` will work no matter what (via
> boxing) so therefore, right, we might as well just support it. Is that
> a reasonable way to put it?
>
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. |kevinb at google.com
> <mailto:kevinb at google.com>
More information about the amber-spec-observers
mailing list