The proposal has a very short statement about implementation. If you think about this very carfully, you realize that part of the compilation speed of go allows you to compile a single package into code without having to leak out all of you abstractions.
If you have contracts/generics then you need to have un-compiled code as part of your exports. Which is a huge break from the current approach.
>We believe that this design permits different implementation choices. Code may be compiled separately for each set of type arguments, or it may be compiled as though each type argument is handled similarly to an interface type with method calls, or there may be some combination of the two.
If the latter approach is taken then no un-compiled code needs to be exported.
Yeah, I'm very interested in how they plan to integrate this into separate compilation. My understanding from C++ and C# is that this is a hard problem.
In Rust, we end up storing the necessary metadata inside of the pre-compiled library, so that when you use it from another library, the compiler knows how to do the right thing.
If you have contracts/generics then you need to have un-compiled code as part of your exports. Which is a huge break from the current approach.