Value types design decisions

[Smith Wilson]

Hello Valhalla community,
I have reviewed the latest documents on the project and have some concerns about current design decisions.

1) Implicit constructor cannot have body.
While I understand why we need implicit ctor and why it must have no args, I still don't understand why we can't allow users to set default values on their own using that ctor instead of implicitly defaulting them to (0, false, null). It could solve problems with such classes like LocalDate which require more special zeroInstance (1970-1-1) than value with pure defaults.
I believe that even String class could be somehow adopted to be value class in future having default null-restricted value of "" with (byte[] value) assigned to empty byte array. Non-final fields (hash, hashIsZero) could be placed into separate final field (i.e. hashHolder) given that it will be forcedly flattened, so there will be no overhead.

2) Implicit constructor must be public.
We all learned that overextending public apis can lead to problems. Great example of this is wrapper classes whose constructors have been deprecated long time ago and still causing a lot of problems. So, new classes (i.e. Optional) were designed to have static factories (Optional#of, Optional#empty), rather than exposing their internal constructors. (Moreover, constructor calls use different byte-code instructions than method calls, which also can cause byte-code incompatibilities in case of future migrations.)
I don't understand why we are going to make same mistake again and why we can't allow implicit constructors to have any kind of visibility modifier. So, VM will be able to freely use zeroInstances where necessary, while user himself will be able to control use of class exposing special apis.

3) Using interface (LooselyConsistentValue) to express non-atomicness.
Same story as with Serializable interface. It is considered that using marker-interface for such a problem was bad design. Although this was justified by the fact that we did not have annotations, it is now unclear what makes us to use interfaces again. While it is possible to come up with real-life use cases of Serializable where type restrictions may be required (some usage of ObjectI/OStream apis), for such VM-close features like non-atomicness there is no real need for such opportunity. (Moreover, we already have some inconveniences because of that. In some cases, type inference of "var" is already blowing up from large type unions like Number & Comparable & Serializable.)
So, I believe we should use alternatives like class modifier or annotation, rather than polluting the type system for no reason.

Regards,
Wilson.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20240120/5aefd8ea/attachment.htm>