Dave Bakker

Results 147 comments of Dave Bakker

I'd say: Discard it. For similar reason as above: none of the existing WASI 0.2.0 & 0.2.1 output stream `close` implementations can fail (*), so dropping them will in practice...

After discussing this further in person, my current understanding is that with Preview 3 streams: - Data flows from the producer to the consumer. (duh.. :zany_face: ) - Closure/failure flows...

Here ya go: ### Python ```py @property def the_property_name(self): return # value @the_property_name.setter def the_property_name(self, value): # update value ``` ### Visual Basic ```vb Public Property ThePropertyName As String Get...

I've got this working in: - https://github.com/bytecodealliance/wasmtime/compare/main...badeend:wasmtime:get-set - https://github.com/bytecodealliance/wit-bindgen/compare/main...badeend:wit-bindgen:get-set - https://github.com/bytecodealliance/wasm-tools/compare/main...badeend:wasm-tools:get-set I used the `get func()` / `set func(..)` WIT syntax and the `[get]...` / `[set]...` ABI encoding as mentioned...

Sounds reasonable to me! 👍 --- > once getters/setters have shipped, add them to WASI interfaces in a subsequent 0.3.y release (using non-conflicting names). > in our next major (probably...

> Is it allowed to return tuple at wit level? Yes. If it has an setter too, the parameter type has to be that `tuple` as well. > What is...

In my branch, only instance methods are allowed to be getters/setters. Freestanding functions & static resource methods are not. Maybe another reason to go for [the annotation syntax](https://github.com/WebAssembly/component-model/issues/235#issuecomment-2622680986)?

A real world example of this is https://github.com/WebAssembly/wasi-cli/blob/main/wit/environment.wit. The current interface is (abbreviated): ```wit interface environment { get-environment: func() -> list; get-arguments: func() -> list; initial-cwd: func() -> option; }...

> My impression is that if we want to (sometimes) have custom getter/setter syntax in generated bindings, then they're sufficiently special that we should give them custom syntax in WIT...

> are you saying that a WIT-level getter/setter `get foo() -> string` in a resource `R` would produce a component-level import named `[method]R.get-foo` (as opposed to `[get]R.foo`)? Correct. > the...