> De: "Brian Goetz" <brian.go...@oracle.com> > À: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "valhalla-spec-experts" <valhalla-spec-experts@openjdk.java.net> > Envoyé: Mardi 8 Janvier 2019 18:44:11 > Objet: Re: Finding the spirit of L-World
> On 1/8/2019 11:20 AM, [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] 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. A the level of the language, very early at the beginning of valhalla, we have talk about a way to annotate equals so == on a numeric value type will be redirected to equals (instead of not compiling like now). This is how you make a numeric value type works like an int. Another primary use case is to be able encode any lightweight functional abstractions like a monad or a cursor without paying any cost at runtime, for those value types, defining == as a numeric comparison make little sense. Rémi >> 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.
