Variant extensions

[guybedford]

Another "nice to have" as opposed to being anything particularly crucial. I was considering use of variants as error types, as it seems like the best option to have fine-grained error information as a sort of best practice. Then there might then be some generic base-level errors which are extended by function-specific error handlers.

At a WIT-convenience level it might be useful to support this via variant extensions:

variant base-error {
  unknown-error(string),
  internal-host-error(string),
  validation-error(tuple<string, string>),
  rate-limit-error(tuple<u32, string>)
}

variant create-error extends base-error {
  invalid-param(tuple<string, string>),
  already-exists(string),
  no-backend(tuple<string, u32>)
}
func create(param: string) -> result<_, create-error>

variant update-error extends base-error {
  update-error(tuple<string, string>)
}
func update(param: string, val: string) -> result<_, update-error>

Similarly, enum extensions might be useful.

Some use cases to think through, just posting as a placeholder for now.

[lukewagner]

Makes sense to me (at some point, as you said). It's even a good question of whether extends would make sense in the component-model binary format to avoid the otherwise binary duplication of cases (which is similarly possible in the gc proposal), which would also allow the component binary to capture this Wit-level information so that it was reproduced on rendering.

[oovm]

I thought about the implementation of abi level, and I proposed #325

I think we can assign a type id to each variant item, and then pass [POINTER, DATA_SIZE] / anyref at the abi level.

So these types form a subtype tree, which can be casted up and down.

Without this feature, the extended type cannot actually be upcast, because the pattern matching of enumeration items is generally implemented as a closed _ => unreachable, and passing the extended type may directly crash.