Comment by stormbrew | Hacker News Reader

Comment by stormbrew | Hacker News Reader

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.

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

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.

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?

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.

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.

Reply on news.ycombinator.com