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 <[email protected]
<mailto:[email protected]>> wrote:
> On Dec 13, 2017, at 5:51 PM, John Rose <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>>
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. |[email protected]
<mailto:[email protected]>
