Nullability of primitive types
Gernot Neppert
mcnepp02 at googlemail.com
Thu Nov 4 08:03:23 UTC 2021
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<T> {
}
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<String> 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.
More information about the valhalla-spec-comments
mailing list