Stream: git-wasmtime

Topic: wasmtime / issue #7383 wasi-http: Fallible fields set and...

Wasmtime GitHub notifications bot (Oct 30 2023 at 17:47):

lukewagner commented on issue #7383:

@pchickey I think (but may be missing a case), that, with the eager-validation changes Trevor made most recently, there isn't a header-related error that can occur in the constructor?

Independently, the discussion made me think that perhaps (in a post-Preview-2 timeframe) we should relax the C-M constructor validation rules to allow constructor functions to return a result<containing-resource-type, T> (for any T). In languages with EH, this would map to the usual throwing-constructor pattern. Otherwise, bindings would produce their best approximation of a fallible constructor.

Wasmtime GitHub notifications bot (Oct 30 2023 at 18:05):

pchickey commented on issue #7383:

The function set: func(name: field-key, value: list<field-value>) -> result<_, header-error>; allows rejecting input, but constructor(entries: list<tuple<field-key,field-value>>); would not allow that same input to be rejected with an error, so currently the implementation traps.

Wasmtime GitHub notifications bot (Oct 30 2023 at 18:05):

pchickey edited a comment on issue #7383:

The function set: func(name: field-key, value: list<field-value>) -> result<_, header-error>; allows rejecting input, but constructor(entries: list<tuple<field-key,field-value>>); would not allow that same input to be rejected with an error, so currently the implementation traps.

I agree we should allow constructors to throw in a post-p2 timeframe.

Wasmtime GitHub notifications bot (Oct 30 2023 at 18:08):

lukewagner commented on issue #7383:

Ah, gotcha; I was thinking about the case of passing in the already-constructed headers.

Last updated: Dec 23 2024 at 12:05 UTC