[estebank]

> don't work with binary libraries,

None of the edition changes that Rust has made have any effect on the ABI. It also has no stable Rust ABI, so there wasn't an effort to formalize that, but 1) ABIs should always be versioned (to avoid getting stuck with a bad ABI) and 2) you can use editions for other kinds of change in the meantime.

> across compilers,

This is almost tautological. Yes, having two C++ compilers agree to their support of editions is the same as them agreeing to their support of concepts. I don't see how this is a critique of the strategy.

> template code across editions, with semantic differences.

Rust defines editions at the compilation unit level: the crate. But it has macros (which are akin to templates) and editions are handled at that boundary (you can have code in one edition invoke macros in another) because the compiler tracks editions at the token level (the information is attached to their Span). There's no reason editions in C++ can't work with templates. You would have to specify the edition of the template, and given C++ semantics you might have to have an opt-in scope to say "use this edition here, override the rest of the file", but it would be possible.

[pjmlp]

Rust editions are very conservative, expect everything to be built from source, with the same compiler, and don't touch semantic changes across versions, mostly grammar changes.

Example, there is no story for scenario, where a callback defined in one version, is used in another crate version, calling into code, using yet another version, while passing a closure with a specific type with semantic changes across all versions.

I am not yet convinced they will scale at the size of industry use cases for C and C++, with a plethora of compilers, and mixing several editions on a 30 year old codebase.