Open wingo opened 2 years ago
PR #48 chooses option (3). But we could just as well do any of the others. Interestingly it would seem that the examples in the overview are still well-typed with this change; the "init"-tracking of locals works out for us.
Thinking about this a bit more, with regards to the dimensions of performance and binary size:
Of course, it still doesn't make sense to consume a null operand :P I still have the feeling that if we have a shorthand, that it should nudge people in the right direction, and so stringref should be non-nullable.
In the GC proposal we standardized on shorthands always denoting nullable references, so it would be good to be consistent with that choice here.
The GC proposal's operations also generally accept nullable inputs and produce non-nullable outputs (where possible), so it would be good (for both consistency and binary size) to do the same here.
Related to the concept of "generally accept[ing] nullable inputs", it would be good to clarify whether the array parameters consumed by string.{new,encode}_*_array
are nullable (I assume they are, but the current text in Overview.md doesn't make that clear).
The only thing in this proposal that can usefully handle a null stringref is
string.eq
. This makes me think that the instructions in this proposal should generally consume and produce(ref string)
, not(ref null string)
.It even makes me think that
stringref
should be a shorthand for(ref string)
instead of(ref null string)
. However all the other shorthands are nullable. My impression is that this is because the other shorthands are abstract; you can use a non-nullable type when you have a little more information on where a value comes from and what you can do with it, but for e.g.externref
you can't do anything with it anyway, so it can be nullable, why not. Also, these top types are appropriate for storage locations (table slots etc) which have to be nullable. So I see the reason for e.g.externref
to be nullable but I don't necessarily think it applies tostringref
, which is a concrete type.Options:
stringref
values to make non-nullable types; #42.)string.eq
to take(ref string)
,(ref stringview_wtf8)
, and so on: non-nullable types.stringref
to be shorthand for(ref string)
instead of(ref null string)
.stringref
(andstringview_wtf8
, etc) shorthands. Just use the two-byteref
forms.Thoughts?
Related to #42, #18, and #14.