Gc: Support for generics

[TomMarius]

Hello,

I was wondering how are 2 different modules compiled to WASM, originally written in 2 different languages, going to cooperate if both support generics - because GC doesn't intend to support generic types if I am not mistaken. What is the plan there?

[Horcrux7]

I think if you have a language with strict generics like C# then the compiled code must check it self at runtime. If you have a language with only compile time generics like Java then there are no checks at runtime.

[rossberg]

The answer has two parts:

1. There are multiple ways to compile generics a.k.a. polymorphism: (1) static specialisation (like C++; functionally limited but does not require any runtime support), (2) dynamic specialisation (like C#; more expressive but requires runtime code generation; is intended to be possible with Wasm but has not been tried in practice yet), (3) universal representations (like many functional or dynamic languages; requires the use of type anyref and downcasts under the GC MVP, see the Polymorphism discussion in the overview).

To support approach (3) more efficiently I assume that will add type parameters to Wasm in a later step. But for the GC MVP you'll have to work around that with downcasts.

1. It's not a design goal for Wasm to guarantee seamless interop between multiple languages, or even multiple compilers of the same language (whether with memory or GC). That is in line with its low-level approach and a very conscious decision: such universal interop has often been promised but never worked out well in practice. Languages are just too different.

If multiple compilers or languages want to be able to interoperate, then they are of course free to define a common ABI on top of Wasm. That would be great! But Wasm itself doesn't need to prescribe it, no more than a CPU architecture does.

[titzer]

To add to what @rossberg says. For (1) static specialization, the language implementation may choose to fully specialize to language-level types (C++ template expansion) or specialize only up to representations (like Scala mini-boxing or levity polymorphism). At the wasm engine level, the only thing that really should be necessary is specializing to representations. This is why imported types in wasm have (or should have--I haven't checked the current state of the proposal, but discussed offline with @rossberg) an expected representation, perhaps restricted to anyref at the moment.

In short, the engine only needs to know representations of types in order to generate code. If code is not properly type-parametric (i.e. does not have the "parametricity" property), then any operator which depends on types has to be properly parametrized (and we have more work to do here).