4 ms·
Rust kind of does this. Language feature uses "edition" and has crates for its standard api instead of built in.
by eadler 4y ago
Rust kind of does this. Language feature uses "edition" and has crates for its standard api instead of built in.
- tialaramex 4y agoIt really doesn't, though, although in principle Editions could provide an escape hatch it would be so drastic as to be largely unthinkable. Because of Rust's commitment to long term stability all of the standard library is there forever, even if it's a mistake and thus deprecated. std::u8::MAX will be in the library forever, even though you can write u8::MAX to get the same constant, name.trim_left_matches(remove) will exist forever even though you ought to write name.trim_start_matches(remove) because "left" assumes an LTR writing system. If NonZeroI64 is a bad idea, too bad it's in the standard library forever. If AddAssign is a bad idea, too bad it's in the standard library forever. The language syntax is allowed to evolve via Editions, but the standard library never breaks backward compatibility.
- actionfromafar 4y agoHey, don't get me started on semantics... what if you trim from the left or right, but are using RTL. Imagine your surprise when the exact opposite happens.
- masklinn 4y agoWhich is exactly why, as GP noted, rust deprecated trim_left/trim_right and added trim_start/trim_end.
- nicoburns 4y ago> It really doesn't, though, although in principle Editions could provide an escape hatch it would be so drastic as to be largely unthinkable Editions don't currently work for the std library, but I don't see why doing so would be drastic or unthinkable.
- tialaramex 4y agoWhereas C++ versions are each distinct languages which aren't necessarily interoperable, Rust Editions promise to interoperate and this is used all over the place. As a result the Editions can only "really" touch syntax, how you in some sense spell Rust, not what it means. Essentially Rust 2015 Edition and Rust 2021 Edition are actually exactly the same language except that the spelling is different, and as a result there are some things you can spell in one that you don't have a way to spell in the other. So in Rust 2015 Edition I can name my function async, because I want to, in Rust 2021 Edition that's fine, but it's written "r#async". Same function, same name in a sense, but different spelling. On the other hand, if I have an actual async function in Rust 2021 Edition, I can't write that in 2015 Edition at all - there's no way to spell the async keyword in that edition. The library however, is mostly semantics, not syntax. We care about what it does, not how to spell things on the whole.
- kelnos 4y agoBut the point is that there's no reason why editions couldn't touch semantics, too. There's no reason why they couldn't add a new attribute #[available_in_editions(2018, 2021)] that could allow them to actually remove deprecated functions, structs, trait, macros, whatever in newer editions. Code written for edition X would still compile and work, but code written for edition Y wouldn't be able to use things marked as unavailable.
- tialaramex 4y agoSo, with this hypothetical attribute, the thing isn't gone, but it doesn't compile any more, whereas with the current situation the thing also isn't gone, and you get a warning (unless you told the compiler to forbid this rather than warning, in which case it doesn't compile). This is identical to a [really_deprecated] attribute. We know it's deprecated but kelnos wants to force us to use a separate crate to use it for some reason.