stringref default value: empty instead of null?

[carlopi]

Current overview says stringref is nullable, while not saying anything about default value for stringview.

Reading https://github.com/WebAssembly/stringref/issues/13 I got thinking whether saying that stringref & stringview are both default constructible to a string of length 0 and a reference to some default constructed stringref respectively.

The basic insight is that, for my understanding, there are no ways to tell null stringref and 0-length stringref apart.

If this is workable, this simplifies both the spec, use of stringview as locals, and also the interaction with JS, since removes the null special case plus the need for a default value:

2. The set of JS representations of stringref values is the set of JS strings, plus JS null.
3. There is no default value for a stringref. If a stringref argument is not supplied, that's an error.

That can just become:

2. The set of JS representations of stringref values is the set of JS strings.
3. Default value for a stringref is "".

[rossberg]

Since string refs would be part of the algebra of reference types (see function type and GC proposal), they'll eventually have two forms like all of them: nullable and non-nullable. And analogous to others, stringref would be the shorthand for the nullable variant. Only nullable references are defaultable, and it's preferable to keep that uniform and not make one-off exceptions for individual ref types.

[carlopi]

Thanks for formalizing and clarifying this @rossberg.

I am not sure where you say that there are nullable or non-nullable variants what 'variants' means, since for example function signature won't distinguish between the two versions (even though the ideal VM might be able to prove certain call sites to have additional properties), so basically here we are adding stringref as nullable, the main value is that it implies that it can progress independently from the formalization of let. Cons is that an extra check is then likely required.

You cited typed function references, also there it's easy to imagine a default value, the function with a given signature composed by a single unreachable, but probably it has been already discussed and discarded.

A semi-related question is whether stringview is nullable or non-nullable.

[rossberg]

I am not sure where you say that there are nullable or non-nullable variants what 'variants' means, since for example function signature won't distinguish between the two versions

With the refinement of typeful reference types, as defined in the func ref proposal, we'll have both (ref x) and (ref null x) (and xref becomes a shorthand for (ref null x)). The function signatures [(ref x)] -> [] and [(ref null x)] -> [] are different types (though they may be in a contra-variant subtype relation).

it's easy to imagine a default value, the function with a given signature composed by a single unreachable, but probably it has been already discussed and discarded.

Yes, this as been discussed. The high-level point is that not all reference types have reasonable defaults, and in the future some will definitely have no known ones (e.g., with type imports or generic types). In other cases, materialising a default may be an undesirable cost. So we have to design the language without that assumption (and resolve the let issue ASAP!).

[carlopi]

Thanks a lot for the information / context.

Closing this then.