4 ms·

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 someti

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.

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.