I wonder why not make the ABI contract explicit, instead of do what C do that froze the lang.

Similar to :

    #[rust_abi]
    struct MustConform
    fn must_conform

So the user must write the shims instead of rust magically build it. This also mean that ABI changes become visible, and changes to rust not mean worries about ABI.

A generic could be seen as a pure (in the functional sense) program that is run at link time that takes various type information as input and outputs an implementation.

You are forgetting C++ has modules now, and extern templates, as implementations for common type parameters.

I would be happy with something better than the C ABI even if it doesn't support everything in Rust on day one.

Thank you for your work, it's always interesting to read your take.

Forgive the naive question on something that's probably been discussed many times over, but could there be a middle ground when it comes to a stable ABI and generics? Something where the person building the library for dynamic linking chooses which explicit monomorphizations they'd like to provide for each public generic function (and type), and the compiler stamps out all combinations of those concrete instances? Could the way these are named and stamped out be standardized so that this could be treated as a stable ABI for non-generics?

It seems to me that it would at least cover distros: they could make a pass over all their Rust code and determine which monomorphizations are needed throughout the distro.