4 ms·
And since one of them may be a default option (i.e., the `nullable` as it's the current state), then it's just: private String? foo; private String! ba
by splix 2y ago
And since one of them may be a default option (i.e., the `nullable` as it's the current state), then it's just:
private String? foo;
private String! bar;
// or
private String foo;
private nonnull String bar;
- demurgos 2y agoYou need an explicit marker for compat with legacy code. The issue defines unspecified as "a null may occur, but we don't know whether its presence is deliberate". Explicit nullability fixes the missing information in older code. There could be other ways to mark opting into strict nullability through metadata at the class, module, package or VM level; but fine grained markers are the less disruptive for gradual migration. In particular this keeps the information local instead of relying on an ambient context.
- splix 2y agoBut the "older code" is already written. And it's written with meaning "a null may occur". It doesn't seem to change anything related to legacy.
- demurgos 2y agoAgreed that the type system treated `T` as nullable, but code may also have comments, annotations and invariants placing stronger constraints. This means that "a null may occur" also lived with "this won't ever be null but the type system does not let me express it" and in the absence of marker it's hard to distinguish both cases.