4 ms·

Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types,

Value types kind of definitively don't have null, right? You can have a zero int but not a null int. So nullability is not entirely orthogonal to value types, its an advantage for value types where they are practical.

gf000 4mo ago
You can have a null int, it's called Integer. What was taken away is the other, identity-having functionality of Integer and similar (e.g. no synchronization).
tsimionescu 4mo ago
This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.
- joe_mwangi 4mo ago
  But with null-restricted types, Integer! and int has no difference semantically and representation. They plan to introduce null-restricted types in future.
pron 4mo ago
I didn't say nullability is orthogonal to value types; I said it was orthogonal to the two-projections world, which is what that text in the article was about rather than nullability. As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best technical in-memory representation for each use. For example, the compiler could choose not to flatten variables that could be null in the heap but to flatten them in the stack. That's the general idea, but I'm not sure about the details, some of which may yet change. More generally than just Java, nullability is often a property not of a type but of a variable. For example, in C, an int may not be null, but a pointer to an int may be. Now, in C, `int` and `int*` are two different types, but that's exactly a distinction that the original projection-spit design made and we wanted to avoid. But you could still end up with a variable that could hold either an integer or a null and another that may hold an integer but not a null, only this is separate from the reference/value projection, which combines both identity and nullability (in C, `int*` is not only nullable, but also has identity).
- ScoobleDoodle 4mo ago
  In case you want to edit it back in: in the 3rd paragraph second sentence, the star in your int* got gobble up by formatting to italics.
- zoogeny 4mo ago
  > More generally than just Java, nullability is often a property not of a type but of a variable. This is a tangent, but I'm not sure I follow this. Can you give an example to make this clear?
  - pron 4mo ago
    Yes, but it comes from Java having both runtime and compile-time types; it's harder to make the distinction in languages that don't have runtime types. In Java, you can ask, `x instanceof T` (and this is a runtime test), which means, is x one of the values in the set of values allowed by T. `null instanceof Integer` is false, even though a variable of type `Integer` can be assigned a null. So you can think of `Integer x` as being `Integer|null x`, i.e. x can hold a null, even though `null instancof Integer` is false.
    - zoogeny 4mo ago
      I think I mostly got this, but just to test it, it would be like in Typescript where I might say: type Foo = { x: number; } type Bar = { x: number; y: number } type FooBar = Foo | Bar; function baz(x: FooBar) { if ('y' in x) { // compiler now knows x is a Bar } } In this case, the variable `x` has a property that is determined by the compiler based on control flow. i.e. it isn't explicitly carried by the type of `x`.
- stickfigure 4mo ago
  > More generally than just Java, nullability is often a property not of a type but of a variable I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the language. Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types. Declaring whole types as non-nullable is less noisy and errorprone than annotating every variable declaration. If you aren't going to give me "declare the whole codebase as non-nullable" then at least give me something coarse-grained.

gf000 4mo ago

You can have a null int, it's called Integer. What was taken away is the other, identity-having functionality of Integer and similar (e.g. no synchronization).

tsimionescu 4mo ago

This won't be true in Java, though - in Java, you will have null Integers at least. It seems that int will remain a different thing entirely from Integer, and will remain a JVM-only concept.

joe_mwangi 4mo ago
But with null-restricted types, Integer! and int has no difference semantically and representation. They plan to introduce null-restricted types in future.

pron 4mo ago

I didn't say nullability is orthogonal to value types; I said it was orthogonal to the two-projections world, which is what that text in the article was about rather than nullability. As to value types and null, I'm not sure about the current picture, but the general idea is that you declare what semantic properties you want - identity or not, nullable or not, tearable or not - and then the compiler picks the best technical in-memory representation for each use. For example, the compiler could choose not to flatten variables that could be null in the heap but to flatten them in the stack. That's the general idea, but I'm not sure about the details, some of which may yet change. More generally than just Java, nullability is often a property not of a type but of a variable. For example, in C, an int may not be null, but a pointer to an int may be. Now, in C, `int` and `int*` are two different types, but that's exactly a distinction that the original projection-spit design made and we wanted to avoid. But you could still end up with a variable that could hold either an integer or a null and another that may hold an integer but not a null, only this is separate from the reference/value projection, which combines both identity and nullability (in C, `int*` is not only nullable, but also has identity).

ScoobleDoodle 4mo ago
In case you want to edit it back in: in the 3rd paragraph second sentence, the star in your int* got gobble up by formatting to italics.
zoogeny 4mo ago
> More generally than just Java, nullability is often a property not of a type but of a variable. This is a tangent, but I'm not sure I follow this. Can you give an example to make this clear?
- pron 4mo ago
  Yes, but it comes from Java having both runtime and compile-time types; it's harder to make the distinction in languages that don't have runtime types. In Java, you can ask, `x instanceof T` (and this is a runtime test), which means, is x one of the values in the set of values allowed by T. `null instanceof Integer` is false, even though a variable of type `Integer` can be assigned a null. So you can think of `Integer x` as being `Integer|null x`, i.e. x can hold a null, even though `null instancof Integer` is false.
  - zoogeny 4mo ago
    I think I mostly got this, but just to test it, it would be like in Typescript where I might say: type Foo = { x: number; } type Bar = { x: number; y: number } type FooBar = Foo | Bar; function baz(x: FooBar) { if ('y' in x) { // compiler now knows x is a Bar } } In this case, the variable `x` has a property that is determined by the compiler based on control flow. i.e. it isn't explicitly carried by the type of `x`.
stickfigure 4mo ago
> More generally than just Java, nullability is often a property not of a type but of a variable I'm going to hard disagree here. And the syntax proposed in the Null-Restricted Value Class Types JEP is a major step backwards. I want to banish nulls from my codebase, completely. I can currently do this with a variety of annotations (at the package-info.java level) and tooling, though it's not integrated well with the language. Forcing exclamation marks into every variable and parameter is a lot of annoying noise that quite simply nobody will do. The default should be non-nullable, especially for value types. Declaring whole types as non-nullable is less noisy and errorprone than annotating every variable declaration. If you aren't going to give me "declare the whole codebase as non-nullable" then at least give me something coarse-grained.