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
