Discussion: alternative future designs

[guybedford]

I understand the reasoning behind the nested result for futures as a take mechanism, but it is still a little unintuitive to use.

I was just wondering about alternatives, and thought it worth bringing up again some of the alternatives.

Alternative 1 - explicit resolved state

resource future-X-Y {
    subscribe: func() -> pollable;
    resolved: func() -> bool;
    get: func() -> option<result<X, Y>>;
}

That is, for get to return none in both the unresolved and resolved cases, with something like a resolved boolean as a distinguisher, alternatively even as an enum state.

Alternative 2 - get variant

Alternatively, a variant can be used to capture the three states with the value only on the one state only returned once:

variant future-state-X-Y {
  unresolved,
  resolved(result<X, Y>),
  taken
}
resource future-X-Y {
    subscribe: func() -> pollable;
    get: func() -> future-state-X-Y;
}

Alternative 3 - static future consumer

More like the finish methods, a method that consumes the future to get its inner result (in some ways this is also more like how promises work in JS, whose values are only consumable through callback functions).

resource future-X-Y {
    subscribe: func() -> pollable;
    static take: func (future: future-X-Y) -> result<X, Y>;
}

I know I missed out on the former discussions, but it might be worth discussing a little, especially given the importance of the future design for preview 3.

[guybedford]

Ahh, of course the static take doesn't work due to the same implicit state assumption, unless it explicitly traps.

Edit: That said, is an explicit trap that bad?

[pchickey]

These are really more wit concerns than wasi-http specifically, though wasi-http has been exercising this area the most - would you mind moving this over to WebAssembly/Component-Model?

[guybedford]

Sure, I don't have access to transfer the issue but can repost if you like.

[lukewagner]

Agreed with Pat that your question is more general than just wasi-http, but it's also not exactly a WIT or Component Model question -- it's more like a cross-cutting WASI convention for "what's the pattern we should use to represent futures in the Preview 2 timeframe before real future<T> is added". Agreed with your observation that the current pattern is rather subtle and your suggestions would make it more intuitive. That being said, Preview 2 is just about done, so the bar for changing it is pretty high atm. My expectation is that mostly the code consuming these pseudo-futures is going to be hand-written low-level glue code, not what's written by regular devs, so that reduces the necessity of having the most intuitive interface somewhat. Thus, I propose we leave things as they are for Preview 2 unless we end up making a significant breaking change before it's stable.

[guybedford]

Closing, since this is primarily a preview3 concern, and any designs should entirely be based on preview3 requirements, as opposed to trying to jump ahead and solve that design work now at this point for preview 2.