Civilizer - let's civilize those primitive types !

[Brian Goetz]

Just a reminder -- this topic is out of scope for valhalla-dev, which is 
for implementation discussions, not language design.

Let's just say that we are more than aware that there is overlap between 
nullity and value types, and that some developers really^3 like the idea 
of having nullity control in the language.  We can leave it at that for 
now.

(BTW this has been explored not only by c#, but by several explorations 
in the Java ecosystem, including the checkers framework and the jspecify 
effort.  (Which are also out of scope for this list.))

On 1/19/2023 3:19 PM, Red IO wrote:
> If we talk about the user model for the explicit nullability of 
> refrences we should think about allowing the developer to turn it 
> around. Meaning that every reference is treated non null when not 
> marked otherwise. But this should definitely strictly be "an option" 
> that you can enable somehow.
> This can be really beneficial since the compiler can mark every point 
> where an (default) non nullable is assigned (potential) null value or 
> a nullable variable is dereferenced at all.
> I just got the idea of inverting the nullability default from c# which 
> has this feature. I recently flipped it on one of my projects and the 
> entire code lit up with warnings. Showing countless spots where a null 
> check was missing.
> It would be logical to use "!" for explicit non-null and "?" for 
> explicit nullable. With 1 being optional in each case rather the 
> default is inversed or not.
>
> Great regards
> RedIODev
>
> On Wed, Jan 11, 2023, 18:30 Anderson Vasconcelos Pires 
> <andvasp at gmail.com> wrote:
>
>     Thanks for the prompt response!
>
>             Mostly prototyping a proposal to remove Q-types
>             (descriptor that starts with Q...;) and replace them by an
>             attribute on methods and fields indicating if the value
>             can be null.
>
>         see
>         https://mail.openjdk.org/pipermail/valhalla-spec-experts/2023-January/002217.html
>
>
>     So if you want to remove Q types it means that L type does not
>     need the identity information, right?
>
>
>         There is no notion of .val or .ref, if you want a field to be
>         flattened, use a @Zero-Default and declare the field @NonNull.
>
>
>     Pretty good if we do not need to use .val or .ref!
>
>     Could the @NonNull be replaced by "!" but writing the attribute in
>     the class file?
>
>     I Like @NonNull but I believe the "!" would be more practical.
>
>     As @Nullable is the default, maybe it would not be necessary to
>     have it.
>
>             yes, the prototype does not do any verification that the
>             compiler does, i'm too lazy for that but the VM will catch
>             you and throw an Error
>
>
>     Pretty good for a prototype!
>
>         About the mutability of fields, fundamentally, value type is
>         about saying, i give up the notion of identity, if you have no
>         identity, you have no location in memory (you can have more
>         than one if you prefer) so the VM is free to pass by reference
>         or pass by value. So you can not mutate a field, because you
>         can only do that if you have one location in memory.
>
>
>     Ok for mutability but now I am a little bit confused about
>     references, identity and memory location. Value class is a
>     reference type that does not have identity. So it means that it
>     can be allocated in the heap, right? So allocating it in the heap
>     will have a memory location, do not?
>
>             regards,
>
>         Rémi
>
>
>     Thanks for the explanation!
>
>     Regards,
>     Anderson.
>
>
>             On Tue, Jan 10, 2023 at 7:39 PM Remi Forax
>             <forax at univ-mlv.fr> wrote:
>
>                 Hi all,
>                 i've developed a small prototype of what the semantics
>                 for the next round could be
>                 https://github.com/forax/civilizer/
>
>                 The prototype works with the latest valhalla early
>                 access build
>                 https://jdk.java.net/valhalla/
>
>                 Basically, everything is an object, using @Value in
>                 front of a class or a record transforms it to a value
>                 class, a class with no identity
>                 (== compares the fields, synchronized throws an
>                 IllegalMonitorStateException, new WeakRef<>(...)
>                 throws an IdentityException).
>                 Adding @ZeroDefault means that the default value of
>                 the value class which is not null is all fields filled
>                 with zero.
>
>                 @NonNull allows to declare a non-null type (there is
>                 also @Nullable which is the default if there is no
>                 null aware annotation).
>                 For parameters, like Kotlin, sending null to a
>                 parameter of a method annotated with @NonNull throws a
>                 NPE.
>                 For a field a zero-default annotated with @NonNull ask
>                 for flattening, trying to store null also throws a NPE.
>                 For a field which is not a zero-default, even if
>                 declared @NonNull, the runtime will *not* throw a NPE
>                 because the field is null before reaching its
>                 initialization assignment in the constructor (and a
>                 constructor can call any methods).
>
>                 From the VM POV, a Q-type never appears inside a
>                 method descriptor. It appears inside field descriptor
>                 but putfield, getfield and withfield allows a field
>                 declared as a Q-type to be accessed as a L-type (this
>                 is currently simulated for getfield and putfield with
>                 an invokedynamic). This is very similar to the way the
>                 VM deals with arrays. And the VM knows if a parameter
>                 is a Q-type or not despite the fact that only L-type
>                 appears in the method descriptor because the Q-type
>                 are declared in the Preload table of the class.
>
>                 It means that if a class/record is not accessed
>                 directly by a constructor but by some static factories
>                 (like Optional) then moving in between an identity
>                 type, a value type (with zero-default or not) are
>                 backward compatible changes.
>
>                 regards,
>                 Rémi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-dev/attachments/20230124/5805e116/attachment.htm>