What we have lost ?

[Brian Goetz]

I would summarize this mail as "no new observations, but growing 
discomfort with ref-as-default."  All of these points amount to "there 
are classes for which most uses will prefer val to varying degrees, but 
users may forget to say .val / avoid saying .val because it is clunky", 
which may turn into performance potholes.  These are surely known, so I 
will take this as Remi worrying that this will be a bigger and more 
persistent irritant than we think.

(I think the idea of "class for which there is no ref type" is a 
non-starter; for all of the types you talk about (vectors, etc), you 
could make the same argument for `int`, but no one is saying we don't 
need `Integer`.  I think what you are really getting at here is coming 
back to some form of "I want val-default".)

A control question I would ask (though let's keep the bikeshedding to a 
dull roar) is how much of this is about the undeniable clumsiness of the 
locution "Point.val".  If, for example, the val type were called "point" 
or "Point!", as some people have already publicly wished, does this 
change your concern that "users will get it wrong all the time"?



On 9/6/2022 4:32 AM, Remi Forax wrote:
> Hi everybody,
> it seems to me that the current design has reached a kind of local maximum, which is nice and not nice at the same time,
> so i would like to take the time to reflect on what we have sacrificed when moving to the current design.
>
> What is missing/not supported by the current model is value classes that should not be used by reference,
> either because it will cause performance issues or because the user will not get the semantics he think he will get.
>
> Here is a list of such value types:
> - unit types, value types like by example Nothing (which mean that a method never returns) with no fields.
>    Because creating a ref on it creates something :)
>
> - wrappers/monads that modify the semantics, by example a generic value class Atomic that plays the same role as an AtomicReference, AtomicInteger, etc
>    the problem here is that the default semantics is not the semantics the user want.
>    
> - SIMD vectors, if those are nullable, the VM/JIT will insert implicit null checks which are not usually a problem apart in thigh loop like users write with SIMD vectors.
>
> - existing value classes in Scala or Kotlin, those are not nullable by default but in the current design, getClass() will happily reflect them with a nullable class making Scala/Kotlin second class citizens of the Java platform.
>
> Those are my 4 tent poles, they are maybe others, but currently we fail to provide a good answer for those cases.
>
> regards,
> Rémi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-observers/attachments/20220907/7cf229a1/attachment-0001.htm>