On 1/8/2019 11:20 AM, [email protected] wrote:
Right. And I'm saying, we can't sell that. Values should work like an
int; you can compare ints with ==. I think the "Currently" story
doesn't wash.
You can not use the "work like an int" argument here, a value type can contain
references, so it doesn't work like an int.
Sorry, I don't buy it.
One of the primary use cases for value types is numerics. Are we
seriously telling people that they can't compare non-intrinsnic numerics
with `==`? I realize that from a VM perspective, the "values have no
==" seems sound, but for the 99.9999% of Java developers that are not VM
engineers, I don't think a single one of them will buy it.
John proposed to stop the recursivity at some point, but it will be very
surprising too !
No, in corner cases like this (and surely this is at least a corner of a
corner), we eat the recursion. That's the sensible equality semantics
for embedding a linked lists in a value.
So for now, i think the only possible semantics is to consider that '==' means
an address comparison for all kind of classes (reference or value class), so a
value class acts like a class for == and given that a value has no address, it
should return false.
That's certainly not the only solution. Nor do I think its a remotely
good one for Java developers.