Announcing Rust 1.96
blog.rust-lang.org
Announcing Rust 1.96
1–10 of 39 posts
Re: Announcing Rust 1.96
#2I 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.
Re: Announcing Rust 1.96
#3I 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.
The full transition won't be completed until 2027 edition, when the meaning of the `..` operator is expected to swap to the new type.
Re: Announcing Rust 1.96
#4I 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.
i came here to comment the same! could not be happier!
Re: Announcing Rust 1.96
#5Woohoo, assert_matches! After all these years!
Re: Announcing Rust 1.96
#6I 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.
It 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.
Re: Announcing Rust 1.96
#7I 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.
When 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.
Re: Announcing Rust 1.96
#8I 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.
When 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.
Both 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.
Re: Announcing Rust 1.96
#9Why 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.
Re: Announcing Rust 1.96
#10I 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.
When 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.
Unlikely, 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.