search

WebAssembly / proposal-type-imports

Proposal for Type Imports & Exports
Other
21 stars 7 forks source link

Has-default-value and nullable as import type constraints #11

Open titzer opened 4 years ago

titzer commented 4 years ago

If we allow non-nullable types in the future, we need to prepare for importing of nullable/non-nullable types.

In particular, suppose a module B imports a type T. Even if we require type imports for now to be only reference types (externref), it would not be future-proof to allow B to use the imported type T in a way that requires a default value, such as a local variable declaration in a function body, because that would preclude T from ever being bound to a non-nullable type.

Therefore I think we should have a "has-default-value" type constraint that specifies that an imported a type must have a default value. This constraint requires any type supplied as the binding for that imported type to have a default value. If an imported type does not have this "has-default-value" constraint, then it cannot be used in any situation that requires a default value for that type.

Clearly, primitive types and nullable types have default values, whereas functions and non-nullable types will not.

Further, we may need to have a "nullable" type constraint that allows ref.null T to be used to supply a value for an imported type T.

titzer commented 4 years ago

@rossberg

Curious if you have thoughts here.

rossberg commented 4 years ago

My feeling is that pushing defaultability further is just gonna metastasise in ugly ways and lead to unnecessary ad-hoc complexity. I'd suggest we treat it as a limited shorthand for types where it makes natural sense, and require explicit initialisation elsewhere.

In particular, in addition to let, we should probably extend the syntax for local declarations to allow an initialiser expressions (like globals), which would be mandatory if the type isn't defaultable. Similarly, for tables. Those are the only two places where defaultability matters, IIRC.

Also note that within the scope of this proposal, type imports are only concerned with type definitions, which describe heap types, and hence are orthogonal to nullability (you can always form nullable or non-nullable refs to them). So attaching defaultability constraints wouldn't even be meaningful for them.