If this is possible, maybe Valhalla's Java could have a user-model
like this:
You should probably start with what problem you are trying to solve.
The poster offered the following clarifications:
The problem it's trying to solve is to remove the .val and .ref
operators/knobs/concepts from the user-model without any loss of
performance or loss of control over nullability, zeroness or
atomicity. In other words, the objective is to take Kevin's
ref-by-default idea one step further.
In theory, we could construct the union type int|Null, but this
type doesn't have a practical representation in memory, ...
Would it be possible to have a value-class give rise to these 3
hidden/runtime-only companion-types on the heap:
RefType - reference to a value-instance or no-reference (null)
ValType - inlined [value-instance-fields]
ValType? - inlined [nullability-boolean + value-instance-fields]
Then, the runtime could transparently choose between RefType|ValType
for non-nullable variables or between RefType|ValType? for nullable
variables, depending on hardware, bitSize, zeroness and atomicity
constraints, as explained by the ternary expression in my previous
email. Of course, since ValType? has a higher bitSize than ValType,
nullable values will be less likely to be inlined. But still, the
point is: could nullable values sometimes be inlined on the heap as
opposed to never being inlined.
In theory, we could construct the union type int|Null, but this
(...) drags in all sorts of mismatches because union types would
then flow throughout the system.
Is my 3-companion-types solution a real union type? Sure, I am
suggesting two sort-of-unions:
RefType|ValType - for non-nullable value-class variables
RefType|ValType? - for nullable value-class variables
However, to the user, both types in each union represent the same
exact value-set.
My comments:
Except the model proposed actually had _more_ knobs than where we are
now: just as many declaration-site knobs (no identity, tearable,
zeroable), and more use-site knobs (atomic, nullable.)
Reading between the lines, what I think is going on here is: ".val is
ugly, can we find a way to spell it !, so we can pretend there aren't
really two things."
And I totally get the desire to do this! But I don't think these are
the droids you are looking for. The overwhelming lesson of Valhalla has
been: every time we try to associate something with nullity (identity,
reference-ness, flattening, atomicity, etc), it turns out to be a mistake.
Would it be possible to have a value-class give rise to these 3
hidden/runtime-only companion-types on the heap:
RefType - reference to a value-instance or no-reference (null)
ValType - inlined [value-instance-fields]
ValType? - inlined [nullability-boolean + value-instance-fields]
I think there are at least two tails wagging this dog here -- the syntax
tail (I want to say ?/!, not .ref/.val) and the performance tail. Note
that the RefType and ValType? in this breakdown are semantically
identical! The only difference is the assumed performance model --
"reference vs inlined." But we *already* can do significant flattening
on the .ref types (calling convention and locals.) If we could achieve
the kind of inlining you want for ValType? in the heap, we would just do
it for RefType too, and we wouldn't need a third thing. So this
breakdown is just making it needlessly more complicated for no benefit.
