Announcing Rust 1.96.0
59 points by theelx
59 points by theelx
assert_matches is a thing I keep wanting and then having to decide if I want a whole new crate or to reimplement it myself. So it's nice to have in the standard library.
Is it weird that I'm excited to remove potentially 100s of pairs of parentheses from my tests? I think not.
I like the steps to make ranges into Copy types. I've run into this once or twice where I was surprised I had to clone a range, and it fits my intuition better that 12..34 ought to be a small, copyable piece of data.
The only thing that worries me is that with multiple types of the same name, VS Code might import the wrong type the next time it adds a use declaration for me.
A Rust version in the near future will also add [...]
core::range::legacy::*as the new home for the current ranges. Range syntax like0..1still produces the legacy types for now, but will be updated tocore::rangetypes in a future edition.
Rust's edition system is seeming like a pretty good idea!
AFAIK whenever there's an ambiguity on imports from a code action VS Code should open a dropdown that lets you choose which one to use.
The only thing that worries me is that with multiple types of the same name, VS Code might import the wrong type the next time it adds a use declaration for me.
I don't think you would regularly need to import these types, right? For most users, the advantage of these new types is small enough to just keep using the regular ones. At the next edition boundary, the new types will be used automatically.
I guess it would mostly be library authors who import the types, because they want to support both version explicitly in some way.
The two are convertible into one another so you can just accept whichever you like and the caller calls .into() on the one they have, or you type your parameter as impl Into<Range> then do the conversion first thing (it’s probably not even worth monomorphising since there’s only two).
Or you work with impl RangeBounds which both implement if that fits your needs.
These new macros have not been added to the standard prelude, because they would collide with popular third-party crates that provide macros with the same name. Instead, they should be manually imported from core or std before use.
That feels a bit weird to me. Is this planned to be changed in the future? Feels like the type of thing we'd like to change in say, three years or so as a minor small cleanup once the ecosystem has moved over.