Lann

> I believe the can all go to the Go package name. That would certainly help with verbosity. I think a nested `///` pattern would work well. Of note here...

> special case top-level errors as being idomatic (try-catch), as distinct from other Result positions. Perhaps something similar might apply to Go? This is what the top post's "most Go...

I think the main issue with (not having) generics is that the `result` and `option` types can be anonymous in WIT, which means you're stuck with awful type names (like...

> `union` It might be nicer to name the variants after the Go types they represent, e.g. ``` union my-union { s32, // MyUnionInt32 u64, // MyUnionUint64 string, // MyUnionString...

> To summarize, IMO having a potentially alloc-free API compensates making it a little bit more verbose. Thanks for the context. I agree that avoiding allocs may be worth slightly...

It seems like there are enough threads in this issue that it may be worth splitting them into separate topic issues, e.g. for generic `variant` improvements vs specific `result`/`tuple` improvements.

`Eq` works this way on purpose for the common case of comparing with variable values. Try: ```go sq.Eq{"c.channel_id": sq.Expr("v.channel_id")} ```

Long ago I considered adding support for other parameter syntax, but it would be a ton of work with squirrel's existing design. I don't think it is going to happen...

Uhh I think I lost track of this back when e2e tests were broken for a while. Will refresh.

Yep, but it could still be reviewed and then I could just merge it after the next rebase :slightly_smiling_face: