5 ms·

I love rust and working in rust has been an incredible experience for me, but I'm probably a really rare case in that I personally hope that the next edition (2

I love rust and working in rust has been an incredible experience for me, but I'm probably a really rare case in that I personally hope that the next edition (2023?) does a little weeding of what's included in the prelude rather than being mostly additive. Specifically, the various magical impls of From are a constant thorn in my side when writing practical rust. Specifically: - Error messages if you screw something up with TryFrom tell you your problem was you implemented From<> wrong because of the magical `impl TryFrom<T, Infallible> for T where T: From` which is confusing as hell. I'm of the opinion this should be removed, and maybe add a macro for helping to implement it if you need/want that. - The magical behaviour of `collect` when given a collection of results to produce a result with a collection causes me to work harder overall because it confuses the type inference to the point that you need to throw a type declaration into the most awkward places. This also happens because of an `impl From` that you can't get rid of. Sure, it's nice that occasionally it does something useful quickly and cleanly, but then it makes things confusing the other 80% of the time. Should just be a separate function.

steveklabnik 5y ago
collect calls FromIterator, so: let five_fives = std::iter::repeat(5).take(5); // this: let v: Vec<i32> = five_fives.collect(); // is equivalent to this use std::iter::FromIterator; let v = Vec::from_iter(five_fives); if you prefer a function-like form.
the_duke 5y ago
> The magical behaviour of `collect` when given a collection of results to produce a result That functionality is incredibly useful though. I use it all the time. But it's also really hard to discover. I've seen quite a few developers be both delighted and very surprised by the possibility. I agree that an extension trait with a dedicated method (like `collect_result`) would probably be better, especially since rust-analyzer can now auto-import traits.
- stormbrew 5y ago
  Yeah, it's one of those things that feels really cool, but the effect on type inference just isn't worth it imo. The fact that I have to put turbofish in sometimes when I'm not using this magic trick just because it exists is the real problem to me. A lot of my opinion on this is informed by my experience in early-days Ruby and C++ with viable templates. It has the feel of the kinds of magic that I came to find very frustrating in both those languages.
  - ibraheemdev 5y ago
    What's your proposed signature of collect? You have to put a turbofish or type annotation because collect works with any collection implementing FromIterator, not specifically Result. Would you have it only work for Vec?
    - stormbrew 5y ago
      I don't have an issue with having to, somewhere, specify that I want a vec or whatever container. The particular thing I'm talking about comes up when you have a long chain of things that involves both results and collect and the type system now needs me to rule out that I want a Result as well, or even a vec of results. If FromIterator<Result> weren't there I believe I'd be able to get away with specifying the final type at the binding instead of a turbofish more often. The other thing is that fairly frequently my goal with collect isn't really to collect anything but to stop processing on an error. Sometimes I need to do this on a couple of layers and the intermediate vecs are gratuitous storage. So my actual proposal would be more like having a simplified version of `scan` that's specifically for iters of results and then it's two steps: process-until-completion-or-error and eventually down the line collect-into-container if I actually want that. Specifically, the weirdness here is that FromIterator<Result> is an implicit conversion between apple-and-oranges container types. Which is quite unlike most (or even all) other FromIterators and it has a complicated type relationship that makes everything else just slightly worse just to give people an ooh-ahh moment when rust does something they don't understand but is helpful.

steveklabnik 5y ago

collect calls FromIterator, so: let five_fives = std::iter::repeat(5).take(5); // this: let v: Vec<i32> = five_fives.collect(); // is equivalent to this use std::iter::FromIterator; let v = Vec::from_iter(five_fives); if you prefer a function-like form.

the_duke 5y ago

> The magical behaviour of `collect` when given a collection of results to produce a result That functionality is incredibly useful though. I use it all the time. But it's also really hard to discover. I've seen quite a few developers be both delighted and very surprised by the possibility. I agree that an extension trait with a dedicated method (like `collect_result`) would probably be better, especially since rust-analyzer can now auto-import traits.

stormbrew 5y ago
Yeah, it's one of those things that feels really cool, but the effect on type inference just isn't worth it imo. The fact that I have to put turbofish in sometimes when I'm not using this magic trick just because it exists is the real problem to me. A lot of my opinion on this is informed by my experience in early-days Ruby and C++ with viable templates. It has the feel of the kinds of magic that I came to find very frustrating in both those languages.
- ibraheemdev 5y ago
  What's your proposed signature of collect? You have to put a turbofish or type annotation because collect works with any collection implementing FromIterator, not specifically Result. Would you have it only work for Vec?
  - stormbrew 5y ago
    I don't have an issue with having to, somewhere, specify that I want a vec or whatever container. The particular thing I'm talking about comes up when you have a long chain of things that involves both results and collect and the type system now needs me to rule out that I want a Result as well, or even a vec of results. If FromIterator<Result> weren't there I believe I'd be able to get away with specifying the final type at the binding instead of a turbofish more often. The other thing is that fairly frequently my goal with collect isn't really to collect anything but to stop processing on an error. Sometimes I need to do this on a couple of layers and the intermediate vecs are gratuitous storage. So my actual proposal would be more like having a simplified version of `scan` that's specifically for iters of results and then it's two steps: process-until-completion-or-error and eventually down the line collect-into-container if I actually want that. Specifically, the weirdness here is that FromIterator<Result> is an implicit conversion between apple-and-oranges container types. Which is quite unlike most (or even all) other FromIterators and it has a complicated type relationship that makes everything else just slightly worse just to give people an ooh-ahh moment when rust does something they don't understand but is helpful.