Multi-value returns vs. adding tuples/structs to type system?

[lachlansneff]

If structs or tuples were added to the wasm type system, then multi-value returns wouldn't be needed, since a function could simply return a tuple or struct.

Since there is no gc in wasm yet, you'd need to be able to create them on the stack.

Being able to store structured data on the stack instead of in a gc allocated space (when the gc extension is standardized) would allow for richer host interfaces and better performance in some cases.

For example,

(type $tuple_i32_i32 (struct (field $0 i32) (field $1 i32)))

(func $swap (param i32 i32) (result $tuple_i32_i32)
        ;; create the struct on the stack
        (create_struct $tuple_i32_i32
                (get_local 1)
                (get_local 0)
        )
)

(func $foobar (result i32)
        (call $swap
                (i32.const 0)
                (i32.const 1)
        )
        (load_field $tuple_i32_i32 $0)
        ;; this would return 1
)

[titzer]

We discussed tuples in various offline settings. There are a couple of reasons we decided against them, all of which essentially stem from the perspective that WASM should be low-level and tuples are a high level concept that can (and should, IMO) be translated away by a higher level language implementation.

In particular, to achieve the goal of making tuples truly zero cost, tuples values and store locations have to be "flattened" or "normalized", instead of being allocated on the heap. This flattening must happen for all places in a module where tuples occur and in all runtime storage locations. This is no problem to do if tuple types occur as parameters, locals, stack values, and (and later fields, array elements, table elements). But, for return values, flattening runs into trouble, similar to how LLVM/Emscripten's handling of struct returns in C, and needs auxiliary storage. Yuck.

When we discussed this two-ish years ago, we recognized the simple generalization of multi-value returns removes the need for tuples altogether in WASM, since tuples can be statically translated away by the language implementation. We reasoned that it is overall better if languages with tuples translated them away rather than the unnecessary complexity of flattening in every WebAssembly engine.

I have also have some personal experience in doing tuples in a high-level language (https://github.com/titzer/virgil) and I can say with some certainty that flattening is a whole lot trickier than it seems at first and that complexity should definitely not be inside a WASM engine, IMO.

[lachlansneff]

Okay, that makes sense. I appreciate you explaining the reasoning behind it.

[rossberg]

Agreed with @titzer. Though for the record, the complexity of tuples that he is referring to only arises when they are given the status as first-class values. As far as I am aware, that was never on the table for Wasm. The first version of the reference interpreter had full support for second-class tuples (back when Wasm still was an expression language). Operationally, that was effectively identical to the current stack machine design, only more restricted (by additional validation-time constraints).

Structs are a first-class notion, however, so Ben's comments apply to them. It's also worth noting that all the same arguments apply to multiple function parameters, which Wasm already has. Multiple results are fully symmetric to multiple parameters. In a stack machine in particular, it is odd not to have both.