3 ms·
It's bizarre to me that there are complaints about the if-else bytecodes. You can call them "weird" but they're very easy to reason about, make it easy to write
by kevingadd 7y ago
It's bizarre to me that there are complaints about the if-else bytecodes. You can call them "weird" but they're very easy to reason about, make it easy to write toy examples, are easier to generate from a compiler, and are easier to read and understand in disassembly. At the point where the author started talking about customized compression to recover the size gains they should have realized why the bytecodes exist! Early on in the spec process it was very, very useful to have them.
Anyone questioning whether the lack of goto was the result of an invocation of veto power can look at the design repo and see that lots of control flow consideration and discussion happened in the open before the group finally agreed upon a solution. Many of the players involved were not Google employees at the time of the decision (I don't know if they are now):
https://github.com/WebAssembly/design/issues/33 https://github.com/WebAssembly/design/issues/33
https://github.com/WebAssembly/design/issues/44 https://github.com/WebAssembly/design/issues/44
I definitely recall that people had disagreements about how control flow should work and had different goals or priorities but it was a pretty detailed and drawn-out decision-making process. I don't think it was really possible for everyone to walk away from the table happy.
- sunfish 7y agoAs context, at the time of those issues, the control-flow restrictions were a compromise to help get the "MVP" off the ground, with the understanding that "more expressive control flow" was expected to be added later: https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#more-expressive-control-flow https://github.com/WebAssembly/design/blob/master/FutureFeat...