Feature idea: Edition dependent names / “replacing” standard library items

:sweat_smile:

10 Likes

I suspect people overestimate how painful big-bang edition updates are / would be.

AFAICT, the reason transitions like Python2 -> Python3 were so painful isn't just that you had to update all your code at once; it's that anybody making the transition cuts themselves off from everything in the ecosystem which hasn't been ported yet. Rust editions don't have this problem.

1 Like

My worry is exactly the opposite. I think that upgrade pain depends non-linearly with respect to the size of the code. That is, upgrades become problematic once you hit 10^6 lines of code or thereabouts. Few people experienced Rust code bases of that scale (for example, I didn't).

Eh, I ported a few-thousand line codebase from sync to async recently and even for the few dozen lines affected, it wasn't trivial to adapt to the new patterns (it took considerably longer than I'd have liked to figure out where all of the async and move keywords needed to go to make the borrowing patterns clear to the compiler).

I think it really depends on the change being made affects each codebase. Basically, it'll be something like Hofstadter's Law where no matter how much work you think it'll be to adapt to some change, it'll be more work than that.

Wouldn’t that order of magnitude mean the code base consists of many, many crates? Each crate can switch editions independently, so in a sense that’s a form of “incrementally updating”, right?

1 Like

I guess it depends on specifics. For example, as a part of 2021 edition preparation (based on this thread, btw :slight_smile: ) I enabled 2021-compatibility lints for rust-analyzer. The way ra CI is setup, lints are enabled globally, and not per crate. One edition-related change was a bit of a head-scratcher. I could have added per-crate lints, and the problematic change was not that hard, but in any that's some extra work. And rust-analyzer isn't that big (200k lines), and very actively maintained.

Wouldn’t

-           let result = f(world.0, params);
+           let result = f({ world }.0, params);

be a better-looking alternative approach to fix this (in the case of an FnOnce like in your case)?


(Also, alternatively, the addition of the let _ = &world; should be enough, you can still use the field then, no need to add an extra destructuring let. Unless the same PR also wanted to make the code easier to understand that way or something like that.)