News for hackers. Stuff that matters.
Re:Rust 1.56.0 and Rust 2021 by EdSchouten on Thursday October 21, 2021 @11:34AM (#28945968)
Yes, in that in C++ it would break if one library used a modern language feature as part of its public header files.
Re:Rust 1.56.0 and Rust 2021 by chc on Thursday October 21, 2021 @12:05PM (#28946533)
Surely the difference there is that Rust doesn't have header files.
Re:Rust 1.56.0 and Rust 2021 by masklinn on Thursday October 21, 2021 @12:10PM (#28946620)
Not necessarily, you could imagine a system where the header file specifies its edition.
Re:Rust 1.56.0 and Rust 2021 by cpeterso on Thursday October 21, 2021 @03:21PM (#28949636)
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
Re:Rust 1.56.0 and Rust 2021 by dralley on Thursday October 21, 2021 @04:00PM (#28950105)
But don't header files generally get concatenated together due to the way "dumb" textual includes work?
Re:Rust 1.56.0 and Rust 2021 by hiccuphippo on Thursday October 21, 2021 @12:39PM (#28947117)
Can't you compile libraries to object files independently with whatever version of c++ they require and then link them together?
Re:Rust 1.56.0 and Rust 2021 by tialaramex on Thursday October 21, 2021 @12:53PM (#28947354)
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.

Re:Rust 1.56.0 and Rust 2021 by MaulingMonkey on Thursday October 21, 2021 @02:12PM (#28948642)
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.

Re:Rust 1.56.0 and Rust 2021 by int_19h on Thursday October 21, 2021 @03:21PM (#28949630)
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.