4 ms·

> Because it requires that library with that API be maintained forever. Why would you say that? Do a cycle of deprecate + remove every few major releases, prov

• pornel 4y ago
  No, Rust has a strong backwards compatibility guarantee. It can deprecate stuff, but not remove. Editions currently don't allow existence of multiple standard libraries, because code from different editions can be mixed.
  • kibwen 4y ago
    Note that editions don't allow multiple standard libraries, but it would be possible (trivial, even) to use an edition-specific lint to deny access to a deprecated function on a newer edition. Even with that, editions don't allow you to expose two different symbols with the same name from the one single libstd so you can't easily "reclaim" or "redefine" an existing function, however since Rust already does mangling it should be possible (though potentially hairy) to expose identically-named functions that resolve to different symbols depending on the chosen edition of the crate. Neither of these things have ever been done, though they have been proposed, and it's just up to the library team to determine if they ever think it would be worth it to do so.
    • nicoburns 4y ago
      I would absolutely love rustc to gain the ability to rename stdlib types across edition boundaries (e.g. you create a Range2 type which is named Range in Rust 2024, or vice versa). I'm not super familiar with the compiler internals, but it seems to me that it shouldn't be all that hairy. One ought to be able to deal with this in a single pass at a very early stage in the compile process. Seems like this would be a great way to deal with deprecated stdlib functionality. Especially in the case that there is a better replacement available. Ranges and channels would be obvious candidates for this.
  • ohbtvz 4y ago
    Well, maybe that policy needs to be amended then. You can't have your cake and eat it too.