You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Components are also able to directly export types, so it is just a temporary WIT limitation that you're not able to define and export the math-class enum directly in the world. We should probably fix that to avoid this question.
The ideal is to somehow have the math-class enum on the root world instead of nested inside a redundant interface name. Unsure if you still want to pursue this.
The text was updated successfully, but these errors were encountered:
I think this is still a good idea. The general goal here is to achieve full co-expressivity between WIT and component-model types and indeed today in component-model WAT, you can define a type:
so it makes sense for us to provide a WIT "rendering" of this raw WAT type. My best guess is that it would look like:
worldw {
exportmath-class: enum { ... }
}
symmetric to how named and unnamed interfaces work. It's mostly just a matter of prioritization and getting someone (with enough WIT tooling experience) to work on an implementation to co-develop with the spec (since the devil is in the details here). I do think we'll want to prioritize co-expressivity before declaring a complete 1.0 though.
Components are also able to directly export types, so it is just a temporary WIT limitation that you're not able to define and export the math-class enum directly in the world. We should probably fix that to avoid this question.
In the meantime, you can also write:
Originally posted by @lukewagner in #295 (comment)
The ideal is to somehow have the math-class enum on the root world instead of nested inside a redundant interface name. Unsure if you still want to pursue this.
The text was updated successfully, but these errors were encountered: