@Gankra The swift dynamic linking article is on HN again and I’m still mad that you didn’t say “where Rustn’t” in the title.
@steve write your own followup article where you detail how Swift's ABI and Library Evolution works in EXCRUCIATINGLY PRECISE terms so you have an excuse to make a better title
@Gankra @steve it’s an absolutely ginormous foot gun but there’s nothing stopping you from doing in! (And even regular templates are dynamically linked in that their symbols are weakly recorded and the runtime linker arbitrarily throws out N-1 of the N addresses rather than complaining about duplicate symbols)
@elfprince13 @steve you're definitely right that I didn't know about the ODR thing and that it lets you dynamically link generic statics in C++, I only learned that a few weeks ago, coincidentally!
Of course the reason I learned that a few weeks ago was because someone was complaining to me that it doesn't actually work because windows(?) doesn't actually support it so if you're trying to write bare-minimum-portable software you can't use it and it may as well not exist :)
@elfprince13 @steve more importantly the claim is still true within the relevant context:
the code is defacto inline (you can't hide the impl from users) and each instantiation of the template is a different symbol/address/code (you can't shove uninstantiated foo<T> into a vtable).
those are the interesting/important properties for the usecases i discuss. statics having equal addresses is comparably... very whatever (though definitely useful if you need it).
@Gankra @steve The “can’t have virtual templates because you can’t generate sensible vtables” is a fun one that I had to recently explain to a Rustacean friend who writes C++ for me at work now. He was convinced Rust solved this problem and I was like “I know it hasn’t or someone would have authored a paper fixing it for C++23 with the same technique”, which led to a deep dive into Rust documentation to the definition of object-safe trait
@steve @Gankra the possibility for ODR nondeterminism with is one of the reasons you’re REALLY not supposed to provide specializations of std:: templates (except apparently specialization of std::hash is allowed as an extension point for your own types, and I think that’s the only allowed deviation)
@elfprince13 @steve conversely i consider anything that doesn't support windows to be useless :)
@elfprince13 @steve did you really not read the paragraphs immediately following that statement