Jump in the discussion.

No email address required.

>Types from the same package with different major (breaking) versions are treated as different types by default

>Here, you can override this for some types by referencing the new major package in the old major package. So dependencies with different versions of the major package can talk with the same type.

its not that crazy. and I am glad that the first point exists, it makes the ecosystem more sane. Otherwise you wouldn't be able to keep track of whether dependencies that use a different version of a package can communicate with the same types.

If this confuses you, good luck working with cmake or whatever C++ stuff. You can't easily interoperate libraries of different versions like this in C/C++ in the first place.

!codecels

Jump in the discussion.

No email address required.

The C++cels should avoid package manager discussions if they want to save face.

Jump in the discussion.

No email address required.

If this confuses you, good luck working with cmake or whatever C++ stuff. You can't easily interoperate libraries of different versions like this in C/C++ in the first place.

Which is why they need to be rewritten in D

Jump in the discussion.

No email address required.

>You can't easily interoperate libraries of different versions like this in C/C++ in the first place.

Going to be honest, why the frick would you ever want to do this? That sounds like something is going seriously wrong.

Is this the modern equivalent of generating piles of cpp and hpp files from XML?

Jump in the discussion.

No email address required.

If I want to use library A and library B version 3.1, but A depends on B version 2.1, then I can do that with rust. Each package (crate?) is self-contained in a way that C++ libs aren't.

Otherwise I would have to upgrade library A to library B version 3.1, which isn't something the creator of library A would have had to consider at the time of publishing. Each crate represents a complete "worldview" of its own code, so you can rely on its propositions (such as the safety or lifetime of some object) as long as you can uphold its assumptions (like what libs it uses).

This enables a ton more modularity of libraries. Instead of using some mega-library like boost, and pinning your whole project and its sub-dependencies to a certain boost version, the individual boost features can all be their own crates. For example consider https://docs.rs/aho-corasick/latest/aho_corasick/ which in C++ would have to be in some mega-library like boost or https://docs.rs/ed25519/latest/ed25519/ which would have to be in some mega-library like libsodium. Each dependency can have its own version of aho_corasick or ed25519 and won't immediately break if you upgrade one thing at a time.

Jump in the discussion.

No email address required.

Link copied to clipboard
Action successful!
Error, please refresh the page and try again.