So basically, once you add generics, kiss your stable ABI goodbye :P? I really care about stable ABIs to the extent that Rust is punting on the issue of space savings and only upgrading dependencies as needed by encouraging making everything static and recompile all time time.
-
-
Replying to @cr1901 @stephentyrone
One could argue that the C compilation model is simply inadequate for languages like C++ and Rust, and having finer grained incremental compilation and/or a JIT for rapid development turnaround would be better
1 reply 1 retweet 3 likes -
Replying to @jckarter @stephentyrone
I suppose, though viscerally I don't like this observation at all. Rust is already so much more complicated than what I wanted in a C replacement (such that it's boggles my mind that an alternate implementation in C++ exists at all).
1 reply 0 retweets 0 likes -
>given that so many language features rely on compile-time specialization What did you mean specifically by this remark? I said "generics" as a catch-all for specialization, but Cyclone (Rust prototype) had generics and was basically a wrapper for C. I assume this meant ABI too.
1 reply 0 retweets 0 likes -
Replying to @cr1901
Weren’t cyclone’s generics tied to pointers so that they still had uniform representation? By default, though, one should assume the answer to “does _language_ care about ABI” is “no”
1 reply 0 retweets 1 like -
Replying to @jckarter
>Weren’t cyclone’s generics tied to pointers so that they still had uniform representation? I have no idea, tbh :P I don't understand why compile-time generics throw such a wrench into obeying an ABI though. Since it's _compile_ time, why can't the compiler look at which >>
1 reply 0 retweets 0 likes -
specialization is currently being generated and then generate the proper prolog/epilog code for the current specialization that obeys said (predetermined!) ABI? The C API could be autogenerated by converting the name mangling inherent in generics to names for humans :P.
1 reply 0 retweets 0 likes -
Replying to @cr1901
A library that publishes generic APIs doesn't know what specializations its clients want. A client can specialize it on its own defined types the original library knows nothing about
3 replies 0 retweets 2 likes -
You can still preserve special compilation by passing enough metadata around to describe the generic type argument. This is what Swift and old, pre-zero-runtime versions of Rust did. It's hard to get right, and requires language design to maintain separate compilation
1 reply 0 retweets 1 like -
Rust has since added type system features that fundamentally require whole program knowledge, though, because impl specializations globally override the trait implementation for the specialized subset of types
3 replies 0 retweets 2 likes
(Though specialization is still unstable)
-
-
So basically, generics ruin implementation simplicity again :P. More seriously from what I can gather, compile-time specialization and incremental compilation (in the shared library sense) are mutually exclusive if the language doesn't have a uniform representation of types?
1 reply 0 retweets 0 likes -
They aren't totally mutually exclusive—Swift and .NET core manage it, as did early versions of Rust—but it takes a lot of nontrivial compiler/runtime coordination and some tricky implementation techniques to pull it off
1 reply 0 retweets 2 likes - 19 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.