4 ms·

This is very cool, maybe this could push the rust community to have a formal specification and a stable ABI in the future.

• steveklabnik 6y ago
  The work on a spec is already going as fast as it reasonably can be. A stable ABI is unclear.
  • rectang 6y ago
    Glad you're going slow on the stable ABI and resisting the pressure to put out something half-baked. The C++ ABI is horribly fragile and complex. Unless the pitfalls of C++ can be avoided, making no ABI promises is better.
    • tumdum_ 6y ago
      No stable ABI makes distributing shared libraries harder :/
      • steveklabnik 6y ago
        Everything is tradeoffs. Stable ABI can also lead to other issues, like performance problems. C++ is dealing with some of these right now, and there are some situations (very very micro benchmarks, to be clear) where Rust is faster than C++ due to ABI issues.
        • pjmlp 6y ago
          That affects mostly GCC and clang, other compiler vendors are more happy to break ABI between major releases, as long as they aren't forbidden by ISO C++ specification. I was already sharing templates and classes across DLLs in Windows 3.x compilers, and keep doing it with VC++ to this day. On Linux with Qt and Gtkmm projects, and on macOS/iOS with their system frameworks. Which is the biggest reason I cannot put up with cargo's model to compile every single project from scratch, after git clone. As we have lengthy discussed, while it might not be a priority right now, it is certainly an adoption block among some Ada, Delphi, Swift, Objective-C, C and C++ communities.
      • chubot 6y ago
        If you want to distributed stable shared libraries, you write to the C ABI, not the C++ ABI. Likewise Rust users should write to the C ABI for stabled shared libraries. (I believe there are a bunch of mechanisms to do that, though I'm not really a Rust user) For example look at what KDE does: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B https://community.kde.org/Policies/Binary_Compatibility_Issu... Yes, you have to do a lot of extra work. That's working as intended. It's sort of an oxymoron to expect to use every C++ or Rust feature in your user-facing ABI and have it be stable. They are incredibly rich languages, with drastically different notions of "function" than C has (let alone other constructs like data layout)
        • steveklabnik 6y ago
          (There are mechanisms to do this, yes)
        • IshKebab 6y ago
          Yes you should do that now but only because Rust doesn't have a stable ABI. If/when it does then there's nothing wrong with distributing shared libraries using the Rust ABI, just like there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff. The C++ ABIs are pretty stable.
          • chubot 6y ago
            there isn't really anything wrong with doing it in C++ nowadays as long as you don't use bleeding edge C++ stuff That's the whole point of the KDE doc I linked. It's not a reasonable strategy to use unrestricted C++, just like it's not a reasonable strategy to use unrestricted Rust. You actually have to design an ABI, not just rely on the compiler to do it for you. I thought there was a GNOME doc too, but I couldn't find it. The point remains: there are lots of things in C++ that people who care about stability don't use at their ABI boundaries.
        • nicoburns 6y ago
          There's also the possibility of an opt-in stable ABI (using the `repr` mechanism). I personally really like the idea of there being an opt-in cross-language ABI at a higher level (or supporting more use cases) than the C ABI (which is quite limiting).
  • Blikkentrekker 6y ago
    Does it not already have them if the programmer elect for it by choosing `repr(C)`, or is there more to it than that?
    • steveklabnik 6y ago
      You are exposing an imprecision in the way that this is usually talked about, yes. If you are willing to use the C ABI, then you can use a combination of that repr and annotations on your functions and produce a shared object in Rust with a stable ABI. What people usually mean here is that Rust would have its own stable ABI, that you would get “for free,” without needing to do that work. (It’s never actually free of course... but that’s yet another detail that is usually papered over when people talk about this.)