Stream: C#/.net-collaboration

Topic: Ideas to make generated bindings more idiomatic


view this post on Zulip Joel Dice (May 31 2024 at 18:15):

I was chatting with Steve Sanderson the other day and he remarked that wit-bindgen currently generates and uses Result and Option types in a pretty literal translation of the WIT input, forcing the application programmer to use e.g. IsOk/AsOk to extract the value, which is awkward. I think I've mentioned before that bindings generators for high level languages which have exception handling should (usually) translate result returns types into functions which return the ok type and throw the err type as an exception (or as a field of an appropriate exception type). Likewise, languages with nullable types should use them to represent option types. You do have to be careful about nested types (e.g. result<result<T, E1>, E2> and option<option<T>> to avoid ambiguity, and sometimes result is used as a field or parameter, so you do end up generating Result and Option types for use in those cases, but in most cases you can do the idiomatic thing.

I've done both those things in the componentize-py bindings generator for Python and would be happy to do the same for the C# generator. Any concerns about that? If not, I'll open an issue on the wit-bindgen repo and start working on a PR.

view this post on Zulip Joel Dice (May 31 2024 at 18:19):

Assuming we're agreed that's the way to go, one thing to determine is how to throw err types as exceptions. Since a WIT file can use any arbitrary type as the err type of a result (including primitives like int and string, or even no type at all), we'd need to decide the most idiomatic way to throw them. Maybe create a WitException<T>: Exception type that works for any T? Happy to defer to the C# veterans on this.

view this post on Zulip James Sturtevant (Jun 03 2024 at 17:08):

I am onboard, That sounds like a more idiomatic approach to handling errors in C# in the majority of cases. We can discuss it a bit more in tomorrows meeting? @Timmy Silesmo @Scott Waye

view this post on Zulip Timmy Silesmo (Jun 03 2024 at 17:18):

Let's discuss it tomorrow!

view this post on Zulip Joel Dice (Jun 04 2024 at 19:10):

I opened an issue for this: https://github.com/bytecodealliance/wit-bindgen/issues/964

Currently, the C# generator generates and uses Result and Option types in a pretty literal translation of the WIT input, forcing the application programmer to use e.g. IsOk/AsOk to extract the valu...

view this post on Zulip Joel Dice (Jun 17 2024 at 15:14):

Finally got CI passing for https://github.com/bytecodealliance/wit-bindgen/pull/968. I'd love to get feedback from the veteran C# devs. I've got two more patches in line behind that PR, one to use nullable types for option<T> and another to clean up some code and style warnings I hit when working on https://github.com/dotnet/runtimelab/pull/2614

This addresses part of #964. For WIT functions returning result<T, E>, we now generate methods which return T and throw WitException such that the E value may be retrieved using WitException.Value....
This adds WasiHttpHandler, a new implementation of HttpMessageHandler based on wasi:http/outgoing-handler, plus tweaks to System.Threading to allow async Tasks to work in a single-threaded context,...

view this post on Zulip Joel Dice (Jun 18 2024 at 22:29):

I've merged the above PR and opened https://github.com/bytecodealliance/wit-bindgen/pull/977 to cover option types.

We now generate bindings which use nullable types (e.g. uint?) to represent non-nested option types. Nested options, such as option<option<T>> still use the Option class except for the innermost o...

Last updated: Dec 13 2025 at 20:04 UTC