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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20171215/4b7daab2/attachment-0001.html>


More information about the amber-spec-experts mailing list