Hooray, congrats to the rust contributors, once again. :)
Personally, not a fan of the match change. But then I was already not a fan of autoderef in method calls.
Rust 1.26 released
21–30 of 178 posts
Re: Rust 1.26 released
#22Earlier quoted context omitted.
The mismatch isn’t about the associated type, it’s about the actual, underlying type. One is a Map and one is a Filter. It’s not possible to determine which is returned, so you inherently need dynamic dispatch. There is some discussion about it possibly being sugar for an anonymous enum in the future, but that’s not what it is right now.
Is there an RFC for the anonymous enum thing? I would gladly write the implementation ... :D
I don’t believe so? I feel like there’s several internals discussions but no RFC yet.
Re: Rust 1.26 released
#23So freaking excited about impl trait. This and not being able to do paramterized array sizes for things like SoA, AoSoA where the two things that I feel like were missing from Rust. Really happy to see the first landing(and I understand work is going on for the second).
There was some sort of SoA derive going around, I thought. Regardless, you’re right; we’re hoping const generics lands in nightly this year and stabilizes early next year.
Re: Rust 1.26 released
#24> Inclusive ranges are especially useful if you want to iterate over every possible value in a range
Out of curiosity, why was the (or an alternative) choice not to make the compiler understand that the 0..256 was not inclusive, and somehow correct the literal value to do what's intended? Would that have been unusually complicated or?
Edit: Overall, still an amazing release, this was just the bit I'm curious about :) Great work by the whole Rust team/community
Re: Rust 1.26 released
#25> Inclusive ranges are especially useful if you want to iterate over every possible value in a range Out of curiosity, why was the (or an alternative) choice not to make the compiler understand that the 0..256 was not inclusive, and somehow correct the literal value to do what's intended? Would that have been unusually complicated or? Edit: Overall, still an amazing release, this was just the bit I'm curious about :)…
Every language I’m aware of has different syntax for inclusive vs exclusive range; making it situational would be quite confusing, I’d imagine.
Re: Rust 1.26 released
#26> Inclusive ranges are especially useful if you want to iterate over every possible value in a range Out of curiosity, why was the (or an alternative) choice not to make the compiler understand that the 0..256 was not inclusive, and somehow correct the literal value to do what's intended? Would that have been unusually complicated or? Edit: Overall, still an amazing release, this was just the bit I'm curious about :)…
Every language I’m aware of has different syntax for inclusive vs exclusive range; making it situational would be quite confusing, I’d imagine.
Definitely agree that having the inclusive syntax makes sense either way (..= was mildly jarring at first but makes complete sense syntactically) - I just mean the exclusive ranges arriving at that compiler error definitely seems unexpected
Re: Rust 1.26 released
#27So, so, so much stuff in this release! The next few are shaping up to be similar. Very exciting times! As always, happy to answer questions, provide context, etc.
In this example: fn foo(x: i32) -> Box > { let iter = vec![1, 2, 3] .into_iter() .map(|x| x + 1); if x % 2 == 0 { Box::new(iter.filter(|x| x % 2 == 0)) } else { Box::new(iter) } } Why is it that I can't return `impl Iterator `? Doesn't the `Filter` type implement `Iterator` for the same associated type?
My understanding is that impl Iterator in return position means that there is some single concrete type that implements the Iterator trait that we are simply not going to name. This way, the compiler can do dispatching statically. If different paths returned values with different types there wouldn't be just a single type that is known at compilation time. That is why the extra indirection via trait objects is required in the example.
Re: Rust 1.26 released
#28Earlier quoted context omitted.
In this example: fn foo(x: i32) -> Box > { let iter = vec![1, 2, 3] .into_iter() .map(|x| x + 1); if x % 2 == 0 { Box::new(iter.filter(|x| x % 2 == 0)) } else { Box::new(iter) } } Why is it that I can't return `impl Iterator `? Doesn't the `Filter` type implement `Iterator` for the same associated type?
I think because returning two different types requires dynamic dispatch when using the returned objects, which requires Box; if the function only returns one type then that type can be determined at runtime and further function calls can be implemented with static dispatch instead.
Rust could generate a bespoke internal proxy type.
Re: Rust 1.26 released
#29Congrats on the release!
Would the book be updated as new features are added to Rust? I see some useful things being incorporated slowly into the language...
Re: Rust 1.26 released
#30So yeah, 1.26 is the most substantial release since 1.0, but there's lots more goodies coming in the pipeline. :) It just so happened that all the initiatives from last year are preparing to land at approximately the same time. For example, coming up next in 1.27 is stable SIMD: https://github.com/rust-lang/rust/pull/49664 (though only for x86/x86_64 at first; more platforms and high-level crossplatform APIs are on t…
The features I'm highly expecting are pinned references and async/await, that will make most of my paid Rust to be so much more readable and maintainable. I know these are coming this year, but any chance they might be already in 1.27?
1.26 has impl Trait, which is one of those things that really makes your life easier as a Rust developer. I've been using beta already with the new API I'm building just to get that feature, now on stable right before I'm actually thinking of deploying the API. Nice.