Reference types, typed function references

[lars-t-hansen]

How will this evolve with (notably) the typed function references proposal? Unless I've misunderstood that proposal, it is possible for the new function types to be self-referential, leading to a non-tree structure being required in the js-types proposal; that's going to be a problem for any textual representation at least.

[Jamesernator]

If maintaining a simple textual/JSONifiable representation is what is desired, in the case of circular types, perhaps we should be exposing the types from a module. If we do this we could just use the numeric indexes in such a representation.

i.e.:

> console.log(WebAssembly.Module.types(someModule)); // FunctionType[]
[
   { 
       parameters: [{ 
           kind: "ref", 
           nullable: false, 
           typeIndex: 1, // points to index 1 in this type table
       }], 
       results: ["i32", "externref"],
   },
   { parameters: ["i32", "i32"], results: ["i32"] },
]

// Suppose we have some exported function, then it might point to WebAssembly.Module.types
// indexes as well
> module.exports.myFunc.type();
{
    parameters: [{
        kind: "ref",
        nullable: false,
        typeIndex: 1,
    }],
    results: ["i32"],
}

This would also explain how WebAssembly.Function can work with typed function references, i.e. you'd just point to type indexes as per usual:

const myWasmFunc = new WebAssembly.Function(
    someModule,
    { parameters: ["i32", { kind: "ref", nullable: true, typeIndex: 0 }],
      results: ["i32", "externref"] 
    },
    (num, func) => {
        const x = func(num, num);
        return [x, new SomeObject()];
    },
);

Although the caveat here is we would need to pass a specific module to the WebAssembly.Function constructor, although it does beg the question, how likely are people to need to specify the types of a new WebAssembly.Function ahead of time, without reference to the module's types that will available in the future.

---

If we don't care about textual representation, then it would be generally just simpler if we had a WebAssembly.FunctionType that might occur in cycles (and ditto for whatever other recursive types might occur in future, like interface types maybe?). If people wanted to produce a textual representation, they could simply assign to each WebAssembly.FunctionType some abstract "index" and serialize a table of them into a format like the above.

This would be a bit less convenient for people wanting to process these types, however it could simply be encouraged that rather than sending these textual representations, one just shares the binary WebAssembly.Module (or the underlying buffer) and just uses .type() on any exported types that they might see. Processing such types wouldn't be hugely different, it's just they couldn't be transferred in the intermediate representation to say a server or something.

[Jamesernator]

Okay so it looks like typed function references actually recently banned recursion in type definitions.

Although something like interface types could still produce them in future, presumably interface types would have a separate reflection API as in that proposal the "interface module" with it's "interface types" are actually a seperate construct from the "real module" and the "real types".

In this regard a textual/tree representation should be viable if we're confident that types (excluding "interface types" for reasons mentioned in the previous paragraph) will never be allowed to be defined recursively. This might be a reasonable assumption, as the core module presumably will need types that are very quick to processs, although it would be awkward if recursive types were added later.

[Jamesernator]

Looking into it further, recursive types will happen but they will part of the gc proposal instead.

So yeah my initial comment will still be relevant with that proposal.