Should all types be exportable?

[alexcrichton]

Right now in the current documentation I believe that all types are exportable but no types can be imported. In discussion with @peterhuene this I believe is because it enables the ability to generate bindings from a binary component more effectively than if no names were specified on types.

Personally, however, I feel like it would be more consistent to now allow all types to be exported, only those which can also be imported. I believe eventually the plan is to be able to import/export "resource" types, but I don't think you're ever expected to import a type char, for example.

I personally think that a custom section with names is sufficient for bindings generation. If a bindings generator wants to be able to generate bindings for any arbitrary binary component then it already has to handle all the cases where types aren't named or things like that. While a name section is possibly easy to omit I also think that on the other hand if a custom section is codified in the spec it's a very clear signal that tools are expected to maintain it.

[lukewagner]

Definitely agreed on having symmetry between imports and exports and yes, in any full MVP, we'll definitely have type imports with at least resource types. But it is a good question of whether non-resource types should be included. Here's some reasons to include:

• I think there are farther-out use cases for importing value types (like char). It takes a bit to fully explain, so I'll not eagerly dump it here (short version: explicitly monomorphizing type-parameterized wit interfaces), but I'm happy to dig into it more if you want. But the upshot is that, in the fullness of time, I think we'll have meaningful use cases for both importing and exporting all typeexpr.
• I've been stumbling towards the principle that everything that shows up in generated bindings (whether AOT via wit-bindgen or runtime via JS API / ESM-integration) should ideally show up in a component's export signature since, in the full view, this is part of the semantics of the component and custom sections are specifically meant to not be part of the semantics so that it's always valid to strip them. E.g., if named exports of types turned into fields holding constructor functions in the JS API, stripping a custom section would change the observable runtime JS interface of a component.
• It's useful for named types to go into the same namespace as the rest of a components' exports so that it's clear that they're in the same namespace and name collisions are not allowed.

[lukewagner]

I think this has been fully answered ("yes") and implemented.