2 ms·
I mean, the core thing is like, you have to have a compiler codebase (and language semantics) that's designed around being able to delay in the first place to b
by steveklabnik 3mo ago
I mean, the core thing is like, you have to have a compiler codebase (and language semantics) that's designed around being able to delay in the first place to be able to even try this, and once you've gotten that in place, well, it's not really about this specific idea anymore.
- tancop 2mo agoWould this work better in a language where generics are vtable based by default and only monomorphized as a form of LTO? If you have a Zig style machine IR where function calls are a "fake instruction" you can decide between direct and virtual call at final codegen time. That would mean generics in shared libraries are possible without hacks but you can always choose to statically link and monomorphize for speed. Libraries could even ship both the vtable based catch all code and specializations for common types as a fast path (but that would probably need a custom dynamic linker).
- steveklabnik 2mo agoIt really depends on a lot of things. This design is possible, yes, but it also means that you can't have some of the same features as Rust has. Rust's traits can be "non-dyn safe" (which used to be called "non-object safe"), because sometimes you cannot use them via a vtable, and must use them via monomorphization. So you can have languages that do things this way, but they make other tradeoffs (either performance ones or power ones, depending).