Rust 1.55.0 | Hacker News Reader

Rust 1.55.0

blog.rust-lang.org

187 pointssteveklabnik27 comments

> Anna Harren was a member of the community and contributor to Rust known for coining the term "Turbofish" to describe ::<> syntax. Anna recently passed away after living with cancer. Her contribution will forever be remembered and be part of the language, and we dedicate this release to her memory.

I don't even program in Rust myself and I've still heard of the term "Turbofish". Rest in peace, Anna

Rust in peace, Anna.

I now realise what the other meaning of this is. I sincerely apologise, Anna. I do wish that you rest in peace, knowing that you made long-lasting contributions to Rust.

Not sure who decided that everyone should suffer from the horrible turbofish operator (::<type>). C++ requires no such monstrosity.

If this operator had been introduced in a corporate language like Swiftlang, it would be the butt of jokes, but community languages like Rust can get away with this by using a cutesy name and everyone is simply too afraid to criticise Rust as they will be the target of intense group-hate.

Uh, maybe you genuinely don't realize this but you're replying to a comment remembering someone who passed away. Which is not the moment to start a syntax holy war.

> Faster, more correct float parsing

> The standard library's implementation of float parsing has been updated to use the Eisel-Lemire algorithm, which brings both speed improvements and improved correctness. In the past, certain edge cases failed to parse, and this has now been fixed.

> You can read more details on the new implementation in the pull request description: https://github.com/rust-lang/rust/pull/86761

There's some pretty big speed improvements there. 3x-10x in the most normal cases, 1600x on some edge cases, and stdlib is now capable of parsing the floats that it never used to be able to.

This release contains array::map, which I consider an exciting feature!

On the face of it it seems weird to duplicate Iterator methods directly on array (which is iterable), but then it really is a special case because this version (thanks to const generics!) should be able to avoid an allocation, which to my understanding isn't possible with the Iterator version

Well arrays never allocate in the first place, but you'd need some sort of specialized iterator api that either:

- Handles the iterator not being the same size as the array you want to collect the iterator into and turns it into some sort of Result<[T; N], ArrayCollectError>.

- By itself knows the exact size of the iterator as part of the iterator type and thus can ensure via the type system that the iterator has exactly as many elements as the array needs.

> By itself knows the exact size of the iterator as part of the iterator type…

std::array::IntoIter<T, N> already satisfies that requirement. The result of mapping over a std::array::IntoIter<T, N> should be std::iter::Map<array::IntoIter<T, N>, F>, which also has the number of elements at the type level and even inherits ExactSizeIterator from array::IntoIter. The problem, I think, is that ExactSizeIterator only says that the size is known at run time; there is no "ConstSizeIterator<N>" trait which would witness that the exact size is known at compile time. If there were then you could potentially collect the items from a ConstSizeIterator<N> (which could be implemented by array::IntoIter<T, N> and inherited by iter::Map<array::IntoIter<T, N>, F>) into an array of N elements without any runtime checks or allocation.

array.map is not inline, it consumes the array and returns another https://doc.rust-lang.org/std/primitive.array.html#method.ma...

But yes in the end this is all done in the stack

We could have an inline version of map (for arrays and Vec) if we had a way to assert that two types have the same size. This means we can reuse the buffer because all elements will fit.

Another "boring" release of Rust, which is exciting.

Aha, wait for the next one. It contains the 2021 edition!

The 2021 edition itself is pretty boring. It only contains a few tweaks compared to Rust 2018, which pioneered such features as Non-lexical lifetimes and Async programming.

Overall it is, but the more fine-grained closure captures and the enabling of array.into_iter are both pretty nice improvements.

This might be the wrong place to ask but does anyone know what’s the situation with fixing Range not implementing Copy? I ran into this the other day again and way annoyed.

https://github.com/rust-lang/rfcs/issues/2848#issuecomment-8...

Thanks, I wasn't sure if there was some other discussion that was not on Github.

If there is I’m not aware of it, but that certainly doesn’t mean there isn’t; I wouldn’t be in the room if there was.

Last update on the issue is from April 25th

https://github.com/rust-lang/rfcs/issues/2848#issuecomment-8...

Not sure why you were downvoted. I also wondered about that when I started with Rust. I'd love to see this at some point but I just started cloning ranges everywhere. As most of my ranges are simple (e.g. just a Range<usize>) the main downside I see is the additional clone calls.

Reply on news.ycombinator.com