Draft JEP on Primitive types in patterns, instanceof, and switch

[Robbe Pincket]

This email was initially sent to amber-spec-observers by accident.



Hi all



I've long considered whether I should voice my opinion on

the matter or not, given that I felt like some of my

arguments had already been made before.



Spoiler, I'm not a fan of `instanceof byte`.



Every time I write this email, I recheck something in

the archives to check something and realize that someone

already said *something* about one of the arguments I'm

trying to make. So here is just a list of things that

have come up that I still felt like mentioning something.



---



I asked a whether the following would be legal in an earlier email.

The draft now explains that it is, but I still wonder what this snippet

would get desugared to.



```

Number num = ...;



if (num instanceof byte b) {

    ...

}

```



---



On 2023-01-27 at 12:01 UTC, Ron Pressler wrote

(as reaction to an email by Remi Forax on 2023-01-27 at 11:06 UTC):



> §4.10.1 of the JLS has stated that a subtyping relationship among primitives exists (byte <: short <: int <: long, float <: double) since at least Java 1.6 (possibly earlier).

>

>> By example, you can not override a method that returns a double with a method that returns an int because overriding is about subtyping relationship, not conversion (for the history, Neal Gafter had implemented method overriding that allow primitive conversions in javac in one of the early versions of Java 1.5 but to it was decided to not go that path).

>

> The rules for return types in overridden methods (§8.4.8.3) doesn’t refer to subtyping but to "return-type-substitutability” (§8.4.5) which, in turn, also doesn’t talk about subtyping but only about subtyping *in the case that the return type is a reference type*. So even though there is a subtyping relationship between int and long (though not between int and double), they are not return-type-substitutable, which places additional constraints beyond mere subtyping.



It seems you missed a single line in the spec. `long` is also a

direct subtype of `float` so `int` is in fact a subtype of `double`



>> I agree that revisiting concepts is something we have to do, but breaking the difference between subtyping and primitive conversions for a corner case, in isolation, is a decision hard to understand.

>

> First, a subtyping relationship for primitives does exist, though it doesn’t cover all of the possible conversions.

Second, nothing is broken, shattered, or wrecked even in cases subtyping doesn’t exist, because the draft doesn’t propose to *change* the meaning of patterns, but rather to generalise them. I.e. its insight is that subtyping is a special case of assignment conversion, and so patterns are “really” about the validity of such conversions rather than about the specific case of subtyping.



I had a quick look over the spec and I couldn't find any place that

actually used the subtyping relation between primitives. The case

you seem to be claiming widening primitive conversion matches 100%

with the rules about subtyping, it actually doesn't use subtyping

at all and just lists all possible conversions.



A interesting question that could be asked is:

"What does subtype/supertype mean". Although it is used in the spec

it isn't really explain apart from being a reflexive and transitive

relationship between types.



---



A few of the emails argue that we should see `instanceof` as a

safe cast check, not like an "inheritance" check or

a "reference subtype" check. If the operator was called

`canbesafelyconvertedto` I might agree, but thats not the case.



It feels very weird (to me) to not have an operator called

`instanceof`, not check whether the lhs is an instance of the

rhs.



Some of you might be thinking: "I guess you want to argue that

you can't have instances of an `byte` so `instanceof byte`

doesn't make sense", which isn't true. Valhalla discussions

have agreed that `byte` has instances. It has 256 different ones:

the values from -128 to 127.



Now this might seem I'm arguing in favour of `instanceof byte`.

And on it's own that might look correct, but then you have

justify the fact that the integer values/instances between -128

and 127 and the byte values/instances are the same. In my mind

the way this would be justified is by using the fact that `byte`

is a subtype of `int` which is why it's set of instances is a

subset of the instances of `int`. But this raises the issue

that the set of instances of `int` can't be a subset of the set

of instances of `float` cause not all ints are valid floats.



---



I feel like I spend too much time writing, rewriting and deleting this

email so this is it (for now).



TL; DR: I don't like `instanceof byte` and JLS chapter 4.10.1



Kind regards

Robbe Pincket


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20230210/c96014cf/attachment-0001.htm>