Civilizer - let's civilize those primitive types !

[Red IO]

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/20230119/caf381fc/attachment.htm>