> 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
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.
> 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.
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.
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.
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.
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.
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.
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.
I submitted the title, as is HN tradition, with the title of the article: "Announcing Rust 1.55.0". At some point in these last 55 releases, Hacker News decided to start cutting off the "Announcing." I don't know why. I haven't been bothered enough to email dang about it to ask, personally.
Titles in the form <Project> <Version> are overwhelmingly unexceptional and clear. And I only used "unexceptional" instead of "common" here as a shy attempt to restore the unbalance caused by the first sentence of your comment.
It wasn't edited by a moderator and our software doesn't know (or care) what language an article is about.
Could you please stop posting off-topic flamewar comments to HN?
Edit: since you've posted so many of these and we've already asked you 3 times to stop, I've banned the account. If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.
if I understood correctly, the word "Announcing" gets automatically removed when submitting. You can then re-edit to re-introduce the word if you really want to keep it.
I don't even program in Rust myself and I've still heard of the term "Turbofish". Rest in peace, Anna