3 ms·

> 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 t

> 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.

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.