[EdSchouten]

Yes, in that in C++ it would break if one library used a modern language feature as part of its public header files.

[chc]

Surely the difference there is that Rust doesn't have header files.

[masklinn]

Not necessarily, you could imagine a system where the header file specifies its edition.

[cpeterso]

A header file can check #if __STDC_VERSION__ or __cplusplus versions to make some code conditionally available for, say, C11 or C++11.

  #if __STDC_VERSION__ >= 201112L
    // C11 feature
  #endif

  #if __cplusplus >= 201103L
    // C++11 feature
  #endif

[dralley]

But don't header files generally get concatenated together due to the way "dumb" textual includes work?

[hiccuphippo]

Can't you compile libraries to object files independently with whatever version of c++ they require and then link them together?

[tialaramex]

Yes. If the only value the library brings to you is that it generates a particular object file, you can divorce that object file from your chosen language version entirely.

If you have libraries that you don't care if they're C or Pascal or a Lisp implemented in raw machine code, then this works just fine and you needn't care about Rust's editions feature. Rust will also cheerfully consume these libraries although of course everything about them is by definition Unsafe in Rust terms.

But most people want their C++ libraries to deliver a bit more than "Here is some machine code, and here are some symbol names that map to the machine code or to raw binary data". Like maybe they want to be able to implement an Interface the library describes, or they want to use a Concept the library names. You can't do those things using language-independent object files.

Rust library A, from edition 2021 can implement a Trait from library B (edition 2018) on its thin wrapper of a type from library C (edition 2015) and then you can consume the resulting type, with its trait implementation, from your Rust 2018 program.

[MaulingMonkey]

The problem is a C++ library's headers must be compiled with the settings, context, and flags of every downstream thing that depends on them, rather than separately.

Which isn't such a big problem if your C++ library exposes a minimal C-like API from it's headers, with most of the meat of the library hidden away in source files, but might be a very big problem if your C++ library is a miserable little pile of ~~secrets~~ templates, a la boost.

[int_19h]

You'd still need the header that describes the public interface of such a separately compiled object file.

Also, this doesn't work with templates, and modern idiomatic C++ tends to be template-heavy.