This repository was archived by the owner on Nov 3, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 3, 2021. It is now read-only.
Missing design rationals for type annotated select #125
Description
After removing subtyping rules (#87) it is unclear for me why we need type annotated select?
Right now we can infer the result type of select in the same way as we do for untyped version.
Is it just for future when we are able to return multiple values from select?
Activity
dbezhetskov commentedon Dec 7, 2020
It is also weird that we can't use ref-types in select without type annotations, it forces engines to add
vec(valtypes)for each select instruction. It is ok sinceselectis a rare instruction but it is still small overhead here that we can avoid.rossberg commentedon Dec 7, 2020
Subtyping has been deferred, but not dropped forever. The combination of subtyping on refs and allowing them as operands to unannotated
selectwould always force us into computing lubs, which we want to avoid. So allowing plain select on refs now would not be future-proof wrt the later addition of subtyping.dbezhetskov commentedon Dec 7, 2020
ah, I see, thanks for the clarification @rossberg .
[WASM-References] Add support for type annotated select
[WASM-References] Add support for type annotated select
[WASM-References] Add support for type annotated select