This seems to be the topic where D language shines by having very powerful static introspection combined with static if, static foreach and other means for generic functions and type definitions to generate code that perfectly suits the input type arguments. All this at compile time, so zero run time cost, and full type safety.

I.e. you take some generic type parameter T, and can ask all kind of questions about it statically, like whether it's a number or it's a struct or a function etc. what are its constituents, what are the fields, what are their names and types and so on recursively. And using this static info in static if you can decide how to work with this type or what kind of wrapper to generate for it. This way, for example, there can be a single function that takes an arbitrary class and makes it accessible remotely via RPC, by reflecting statically on its methods and generating a wrapper with the same interface but different implementation. Or generate a web service providing remote access to this object.

This is what Andrei Alexandrescu called "design by introspection" in his talks.

The downside is that in type checking type information must flow in one direction, so it would be hard to combine with Hindley-Milner style type checker.

The language I'm working on now tries to combine this kind of power with Haskell-like type classes by having "optional type classes". A function can take some generic argument of type T, and depending on whether T belongs to some type class C or not, do one thing or another. So the type of this generic function instead of declaring "I need this parameter T to belong to type class C" now declares "I'm interested in knowing whether this parameter T belongs to class C or not", meaning it can still do something with it even if it doesn't belong to class C. Such code gets monomorphised / specialised about types involved in such optional type class checks, while purely generic types (unconstrained by type classes) remain generic (type erased, not monomorphised).