Remix clone Hacker News

Something that Rust got _really_ right: Editions. And not just that they exist, but that they are specified per module, and you can mix and match modules with different Editions within a bigger project. This lets a language make backwards incompatible changes, and projects can adopt the new features piecemeal.

If such a thing came to C++, there would obviously be limitations around module boundaries, when different modules used a different Edition. But perhaps this could be a way forward that could allow both camps to have their cake and eat it too.

Imagine a world where the main difference between Python 2 and 3 was the frontend syntax parser, and each module could specifically which syntax ("Edition") it used...

▲

CrendKing 14 hours ago | parent | next [-]

But Edition can exist only because Rust intrinsically has the concept of package, which naturally defines the boundary. C++ has nothing. How do you denote a.cpp be of cpp_2017 edition which b.cpp be cpp_2026? Some per-file comment line at top of each file?

C++ is a mess in that it has too much historic baggage while trying to adapt to a fiercely changing landscape. Like the article says, it has to make drastic changes to keep up, but such changes will probably kill 80% of its target audiences. I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go. It is time to either switch to Rust, or pick one of its successor languages and put effort into it.

▲

umanwizard 8 hours ago | parent | next [-]

Rust doesn't have the concept of package. (Cargo does, but Cargo is a different thing from Rust, and it's entirely possible to use Rust without Cargo).

Rust has the concept of _crate_, which is very close to the concept of compilation unit in C++. You build a crate by invoking `rustc` with a particular set of arguments, just as you build a compilation unit by invoking `g++` or `clang++` with a particular set of arguments.

One of these arguments defines the edition, for Rust, just like it could for C++.

▲

ynik 3 hours ago | parent [-]

That only works for C++ code using C++20 modules (i.e. for approximately nothing). With textual includes, you need to be able to switch back and forth the edition within a single compilation unit.

	▲	epage 42 minutes ago \| parent [-]
		Mixing editions in a file happens in Rust with the macro system. You write a macro to generate code in your edition and the generation happens in the callers crate, no matter what edition it is.

▲

hypeatei 14 hours ago | parent | prev [-]

> I think putting C++ in maintenance mode and keep it as a "legacy" language is the way to go

I agree but also understand this is absolutely wishful thinking. There is so much inertia and natural resistance to change that C++ will be around for the next century barring nuclear armageddon.

▲

actionfromafar 13 hours ago | parent | next [-]

I don't think even that would suffice. :)

▲

adgjlsfhk1 13 hours ago | parent | prev [-]

Cobol's still around. Just because a language exists doesn't mean that we have to keep releasing updated specifications and compiler versions rather than moving all those resources to better languages.

	▲	AnimalMuppet 13 hours ago \| parent [-]
		COBOL's most recent standard was released in 2023, which rather ruins your point.

▲

wink 2 hours ago | parent | prev | next [-]

My C++ knowledge is pretty weak in this regard but couldn't you link different compilation units together just like you link shared libraries? I mean it sounds like a nightmare from a layout-my-code perspective, but dumb analogy: foo/a/* is compiled as C++11 code and foo/b/ is compiled as C++20 code and foo/bin/ uses both? (Not fun to use.. but possible?)

Is that an ABI thing? I thought all versions up to and including C++23 were ABI compatible.

	▲	zozbot234 an hour ago \| parent [-]
		How does foo/bin use both when foo/a/* and foo/b/ use ABI-incompatible versions of stdlib types, perhaps in their public interfaces? This can easily lead to breakage in interop across foo/a/* and foo/b/ .

▲

SkiFire13 4 hours ago | parent | prev | next [-]

> And not just that they exist, but that they are specified per module

Nitpick: editions are specified per crate, not per module.

---

Also note that editions allow to make mostly syntactic changes (add/remove syntax or change the meaning of existing ones), however it is greatly limited in what can be changed in the standard library because ultimately that is a crate dependency shared by all other crates.

▲

humanrebar an hour ago | parent | prev | next [-]

The C++ profiles proposal is something like an "editions lite". It could evolve into more fully featured editions some day, though not without some significant tooling work to support prevention of severe memory and type safety issues across different projects linked into the same program.

▲

steveklabnik 13 hours ago | parent | prev [-]

There was a similar proposal for C++, using rust’s original names: epochs. It stalled out.

	▲	ykonstant 4 hours ago \| parent [-]
		They should call them 'eras'. Then they can explain that epochs did not lead to a new era in the language, but eras will mark the next epoch of C++.