WebAssembly / stringref

Other
37 stars 2 forks source link

stringref should be non-nullable by default? #47

Open wingo opened 2 years ago

wingo commented 2 years ago

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 to stringref, which is a concrete type.

Options:

  1. Leave as is: instructions consume nullable types. (Though, we recently changed instructions that produce stringref values to make non-nullable types; #42.)
  2. Change everything except string.eq to take (ref string), (ref stringview_wtf8), and so on: non-nullable types.
  3. (2), but also change stringref to be shorthand for (ref string) instead of (ref null string).
  4. (2), and remove the stringref (and stringview_wtf8, etc) shorthands. Just use the two-byte ref forms.

Thoughts?

Related to #42, #18, and #14.

wingo commented 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.

wingo commented 2 years ago

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.

tlively commented 1 year ago

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.

jakobkummerow commented 1 year ago

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).