8 ms·
Announcing Rust 1.96
- Tuna-Fish 4mo agoI honestly didn't expect the ranges to be ever fixed, I just expected they would remain as an eternal wart. I wonder how painless the transition will be.
- whereistejas 4mo agoi came here to comment the same! could not be happier!
- estebank 4mo agoThe full transition won't be completed until 2027 edition, when the meaning of the `..` operator is expected to swap to the new type.
- ameliaquining 4mo agoIt came pretty close to happening in Rust 2024, but it was determined that there just wasn't enough time left before the end-of-year deadline to roll out such a big change.
- TazeTSchnitzel 4mo agoWhen the new edition rolls around that swaps to the new type, I expect a bunch of libraries are going to get really annoying to use. And vice-versa for new libraries with the old editions.
- yuriks 4mo agoBoth types have the `From` conversion traits implemented between each other, so in most cases interoperating with APIs using the old type should be as simple as doing `(1...4).into()`. And, probably because of the warts of the old types, I haven't seen them used much in APIs, so even that I don't think will happen very often.
- pornel 4mo agoUnlikely, since library interfaces need to use a trait to accept all of the open/closed inclusive/exclusive syntax variations. If the only accept one specific named range type, they're clunky already.
- pjmlp 4mo agoI will watch it quite interested, as it tends to be an example I give where editions don't really work as people expect.
- mountainriver 4mo agoWith AI assisted coding I imagine no one will notice It’s a new world for breaking things
- PoignardAzur 4mo agoWoohoo, assert_matches! After all these years!
- j1elo 4mo agoWhy replace the already existing std::range in-place with the new version, and move the old one to std::range::legacy? That's confusing and not forward thinking, what if a design improvement is found in some years and a new iteration is wanted? Will it end up as a std::range::legacy::legacier? The other day there was some talking about Go's stdlib around here, and I truly believe they got it much better thought out. std::range should stay where it is, and the new one be introduced as std::range/v2 or std::range::v2 or whatever syntax was deemed adequate. Solving the problem of how to iterate the stdlib in a maintainable and consistent way would also help to take away the reservations against adding actual batteries to the stdlib. The old adage against adding APIs because "once a new API enters the stdlib, it has to stay like that forever" has meant that Rust never takes a stance to pick a set of opinionated choices for the majority of the community who just want an "official" language-vetted way to get stuff done.
- metaltyphoon 4mo ago> std::range should stay where it is, and the new one be introduced as std::range/v2 Isn’t this what editions are for?
- estebank 4mo agoYes, but no, but also yes. Editions are for language evolution. Evolving the std does fit the bill. Edition aware path resolution isn't a thing. It will likely be a thing starting with Edition 2027. Range is likely to be the first type to use this feature upcoming.
- pjmlp 4mo agoWhich is why I always give library evolution as one example why editions don't solve everything as many people think they do.
- metaltyphoon 4mo agoDon't let perfect be the enemy of good enough. This is much better, IMO, than what many other languages do, including Go's modulename/v2 style.
- 7e 4mo agoWhere is the fork of Rust that accepts AI contributions? We need that desperately.
- steveklabnik 4mo agoThe Rust language does not currently have an LLM policy, but the one under discussion is not a total ban.