From mcnepp02 at googlemail.com Thu Nov 4 08:03:23 2021 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Thu, 4 Nov 2021 09:03:23 +0100 Subject: Nullability of primitive types Message-ID: Dear experts, regarding the ongoing debate about nullability of primitive classes: even though we are talking about nullable vs. non-nullable _types_, wouldn't it help to focus on null-permitting _usecases_? There are class-members, method arguments and return-values of primitive-class types. IMHO, it would make real sense to defer the decision of permitting nulls to each of these use-sites. The "nullability" would be represented at each _use-site_ by the corresponding Descriptor (L vs. Q) in the class-file, and the _default_ would (obviously) be "L" for normal classes, and "Q" for primitive classes. Given a primitve class java.util.Complex, the descriptor for a class-member declared "Complex number;" would be "Qjava.util.Complex;" wheras the descriptor for a class-member declared "@Nullable Complex number;" would be "Ljava.util.Complex;" Likeweise for method-signatures. That way, there'd be no need to have two different class-mirrors for a primitive class. Of course, you would be able to query the "nullability" of a java.lang.reflect.Field or a java.lang.reflect.Parameter via Core reflection. However, the API for obtaining java.lang.reflect.Methods would not need to be changed at all! Two methods whose signature only differed by "nullability" (aka L vs Q signature) would be considered the same, thus the following would not be allowed: class ComplexCalculator { Complex add(Complex one, Complex two); @Nullable Complex add(@Nullable Complex one, @Nullable Complex two); } As for migration of existing none-primitive classes to primitive ones, it would be possible to make @Nullable the default _usecase_ for a primitive class: @Nullable primitive class Optional { } Then, for orthogonality, there'd be a means of specifying "Use this primitive type as a non-nullable value here", maybe something like @ByValue Optional getName(); (As a sidenote, maybe a good name instead of @Nullable would be @ByRef). And yes, with this proposal the Java primitive types (int, long...) would remain special cases, and they would continue to have their "companion" reference-types.