[jbiason]

(Just to be sorta pedantic) I don't think it's the version 1.x that promotes backward compatibility, but editions.

In 2016, you could call your function `fn async(...) { ... }` without any issues, and you can still compile this code with the modern version of rustc. If you want to use the async features of Rust, you need to change your edition to at least 2018, which brings breaking changes in the language.

And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate.

(So, I guess the ideal world would to first look at the package management in Python, and *then* try to introduce breaking changes. And I'm withholding how much I'm angry at the PSF for postponing having a decent package manager for 20 years and investing in removing the GIL and adding JIT.)

[0cf8612b2e1e]

Not meaning to apologize for Python here, but you have significantly more ability to segregate “editions” when you statically compile code.

All the more reason to take a breakage very seriously. This is even worse than the walrus operator. At least I can ignore that. This breaks working code for some notion of purity.

[roblabla]

Code compilation doesn't really have much to do with it. Python already has a somewhat similar ability - opting into certain language features of python on a file-by-file basis - using __future__[0]. It'd be pretty easy to add something like Rust editions by looking for a special statement in the file. And to make it more convenient, put it in the __init__.py and have it be transitive to the module.

[0]: https://docs.python.org/3/library/__future__.html

[drdaeman]

> And you can have a project that mixes those editions, and cargo will correctly use the edition asked for each crate.

I'm curious - if you had a `pub fn async(...){...}` in some 2016 crate, can you still call it from a 2024 codebase?

[Lorak_]

You can: https://doc.rust-lang.org/rust-by-example/compatibility/raw_...

[drdaeman]

Wow, this is nice and looks well thought out. Thank you!