Bugzilla

Ah, ok, thanks for explaining.  I was worried about sticking vectors into vectors, but I see what's going on.  Pushing block params/results onto the stack has some nice regularity properties.  One worry, maybe it's too theoretical, I dunno, is that there could be large block signatures that are used repeatedly in a function (noting that a block with signature T^N --> T^N doesn't need to contain N instructions, it can just be empty, and so there could be O(N*M) copying for M bytes of bytecode).  Another theoretical O(N*M) case is if you deeply nest blocks with big signatures.

I think you're right that the super-common case is and will be `[]->[]` and `[]->[valtype]`, but I think inlining+branch-predication will make the packed-word representation no worse than the more homogeneous representation.

Are there any problems introduced by representing block types as indices into the type section that are solved by copying them onto the stack?

> Also, the FuncTypeRef / ResultTypeRef formulation avoids introducing the concept of a BlockType into the source.

This is more aesthetic, but personally I think the relationship between valtype, resulttype, functype and blocktype is complicated enough that I found it nice to have `ValType`/`ResultType`/`FuncType`/`BlockType` C++ types that correspond 1:1 with what's written in the spec ([e.g., for blocktype](https://webassembly.github.io/multi-value/core/syntax/instructions.html#syntax-blocktype)).

Ah, ok, thanks for explaining.  I was worried about sticking vectors into vectors, but I see what's going on.  Pushing block params/results onto the stack has some nice regularity properties.  One worry, maybe it's too theoretical, I dunno, is that there could be large block signatures that are used repeatedly in a function (noting that a block with signature T^N --> T^N doesn't need to contain N instructions, it can just be empty, and so there could be O(N\*M) copying for M bytes of bytecode).  Another theoretical O(N\*M) case is if you deeply nest blocks with big signatures.

I think you're right that the super-common case is and will be `[]->[]` and `[]->[valtype]`, but I think inlining+branch-predication will make the packed-word representation no worse than the more homogeneous representation.

Are there any problems introduced by representing block types as indices into the type section that are solved by copying them onto the stack?

> Also, the FuncTypeRef / ResultTypeRef formulation avoids introducing the concept of a BlockType into the source.

This is more aesthetic, but personally I think the relationship between valtype, resulttype, functype and blocktype is complicated enough that I found it nice to have `ValType`/`ResultType`/`FuncType`/`BlockType` C++ types that correspond 1:1 with what's written in the spec ([e.g., for blocktype](https://webassembly.github.io/multi-value/core/syntax/instructions.html#syntax-blocktype)).