Lann

Another relevant example: https://github.com/bytecodealliance/wasmtime/blob/71d0418e4fbf203090e11f9928e36bc12a11437a/crates/wasi/wit/deps/http/types.wit#L47 > `new-fields: func(entries: list) -> fields` (note that this doesn't represent a map; http headers can have repeat keys)

I'd be interested to hear more about the desire to avoid generics. The bulk of my Go experience was pre-1.18 and I haven't really used them enough to form my...

https://github.com/bytecodealliance/wit-bindgen/issues/612#issuecomment-1639655039 by @qmuntal points out a potential performance optimization allowed by struct wrappers. It would be worthwhile to (micro-)benchmark the two approaches to get an idea of the potential performance...

If we're going to generate wrappers for results I'd like to understand the naming scheme for those wrappers. It seems quite easy to end up with conflicts, especially with combining...

> My trivial algorithm would be PackageName+FunctionName+ParameterIndex. WIT `result` types can appear anywhere any other type can, so we would need at least a fallback algorithm for wrappers that aren't...

I don't think _anyone_ has enough experience writing WIT to gauge how practical particular examples might be. :slightly_smiling_face: Here's one that feels to me like it has a plausible shape:...

> `variant` A common representation of "sum types" in Go is a "sealed" interface: ```go type C1 interface { // The method is unexported so other packages cannot implement this...

> long and repetitive function and type names > `` Is there some inherent limitation that prevents us from putting each interface (or at least package) in its own Go...

> `option` Assuming we can find a way to turn `fallible: func() -> result` into `Fallible() (T, E)`, we could similarly turn `optional: func() -> option` into `Optional() (T, bool)`....

> do you think the "sealed" representation is better than the current one? I personally prefer it, and I think it is a more conventional pattern in Go. Protobuf's generated...