Should aliases be allowed in module types?

[alexcrichton]

With #29 components can now directly embed core wasm types sections, namely being able to define func types for example. This, unlike before, enables aliasing types in module type definitions unlike before where doing so wasn't necessary since there was nothing valid to alias.

With this new structure, would it perhaps make sense to allow aliases to appear in module type declarations? Similar to component/instance type declarations. Validation would ensure that only core type aliases are valid and additionally only non-module-type imports/exports would still be allowed for now.

[lukewagner]

That's a really great question and indeed, the first draft of #29 did include core aliases in core module types exactly like you're talking about. The reason for removing it at the time was thinking that, if a module type can outer-alias a function type, then the module type needs to pull in the whole component nesting tree, which felt like a layering violation (core stuff should only refer to other core stuff). But thinking about this again from a fresh perspective: it's already the case that core type definitions can refer to preceding core type definitions in the same component, so it would make total sense to say that a core outer alias inside a module type could refer up to (but not beyond) its innermost enclosing component's core type section. And that actually could get you pretty far, in terms of de-duping core types: they could all be hoisted up to some common component's type section and then aliased into each nested component, noting that (non-core) aliases can target core sorts.

So yes, I'll add them back. Thanks for bringing this up!

[Liamolucko]

Can this issue be closed now?

[alexcrichton]

Indeed!