Addressing the full range of use cases

[Maurizio Cimadamore]

On 06/10/2021 10:56, Remi Forax wrote:
>> - Existing class types like LocalDate are both nullable and atomic. These are
>> useful properties to preserve during migration; nullability, in particular, is
>> essential for source compatibility. We've provided reference-default
>> declarations as a mechanism to make reference types (which have these
>> properties) the default, with 'P.val' as an opt-in to value types. But in doing
>> so we take away the many benefits of value types by default, and force new code
>> to work with the "bad name".
> The existing class LocalDate is not atomic per se, atomic in Java implies volatile and currently if a LocalDate field is updated in one thread, another thread may never see that update.
> LocalDate is currently not tearable, a QLocalDate; is tearable in case of racy code.

The fact that QLocalDate is tearable is a consequence of the fact that 
e.g. elements of a QLocalDate[] cannot be read/written atomically - e.g. 
in a single shot, unlike for references - which are pointers and can be 
loaded/stored atomically (as per Java Memory Model).

It's true the word "atomic" is sometimes used to refer to operations 
such as CAS which provide strong inter-thread guarantees - this is not 
what Dan had in mind here.

Maurizio