On 6/9/2020 7:00 PM, Kevin Bourrillion wrote:
On Tue, Jun 9, 2020 at 2:18 PM Dan Smith <[email protected]
<mailto:[email protected]>> wrote:
A few things that still make me a bit uneasy, maybe could use more
noodling:
- "Inline value" vs. "reference value" makes sense. Then re-using
"inline" for "inline class" vs. "identity class" is potentially
confusing. In this context, we're using "inline" as shorthand for
"inline-capable" and "identity-free". It would sort of be nice if
we could flip the world and make 'identity' the class declaration
keyword (although we'd still need a term for the absence of that
keyword).
My current way of spinning this to myself is that a class being
"inline" means it /enables/ possible inlining, /and/ that referring to
it as an "inline" type (its concrete type) is another step that also
/enables/ possible inlining, and in the end the VM will do what it
wants, subject to those limitations. So, I can see the term working at
both levels...
Perhaps the problem is that we've put the term on the secondary
attribute rather than the primary. The primary attribute is id-freedom,
from which we derive the option to inline. But we're calling them
"inline".
- The syntax ".val" used to denote an "inline type" is a bit of a
mismatch. Maybe we want a new syntax. Or maybe we want to rework
the word "value" into the story so that "inline type" becomes
"value type".
This was my reaction too. ".val" means "the value itself, that you
care about", and ".ref" means "a reference value that points to the
value you care about", but I used the word "value" /more/ times in the
second phrase. It doesn't feel like this will be clear.
My intention here was to appeal to terms many users already understand:
pass by value and pass by reference. That's why `V.val` is not `V.inline`.
