Hacker News Reader

Comment by overthrow | Hacker News Reader

> BUT when you try to use it with iterators -- which are also amazing, I love using iterators -- IT DOESNT WORK.

Yes it does

  let res: Result<Vec<_>, _> = iterator.iter().map(|x| x.foo()).collect();
  let res = res?;

> But this also happens elsewhere, because of this ugly inflexability, we cant do:

Use and_then:

  let z = x.foo().and_then(|y| y.bar())?;

I get that there's an upfront cost to learning this stuff, but I think he's blaming the language a little too aggressively.

View on HN

Yea, it's a game i often play. "Boy it would be nice if i could do X" where X is something like `and_then`, and then i go look it up in the stdlib and.. it's there.

For a good while my X's were a nightly only experimental API, but slowly and surely they make it into stable. (Hash|Btree)Map's `.entry` methods (and friends) were another example.

Generally speaking these methods are super helpful and someone else already thought of it. From my experience at least.

.. also this article was infuriating hah.

Also,

  let res = iterator.iter().map(|x| x.foo()).collect::<Result<Vec<_>, _>>()?;

I love rust because it satisfies my inner perl

And people complain about ))) in Lisp...

It is a non-obvious Rust-ism that if you’re doing something with iterators and you don’t know how, it’s probably .collect(). ;-)

Kind of like how the answer is always ‘traverse’ in Scala.

.collect() gets overloaded a lot to deal with the intricacies of the return type, which usually says a lot about the computation, e.g. Result or HashSet.

It just reads better in terms of code.

`let res: Result<Vec<_>, _> = iterator.iter().map(|x| x.foo()).collect();`

Left to right reading this statement is "iterate over the values and map it to the output of foo for each value. Then collect that map into a vector."

His other example

``` for (i, x) in something.iter_mut().filter(|| {...}).enumerate() { x = (x) * i } ```

can also be read from left to right as "iterate over something, then filter and enumerate the values"

It's much more explanatory than top down structures with 10 lines to explain the same thing.

It's not the same.

Using the question mark in a closure in general is confusing.

Doing ? on the return value of a statement doesn't make sense. Normally ? is used for: here is this Result (I forgot the trait's name), and give me the Ok(), and if it is Err() then RETURN to the caller.

So the function itself must be of type Result<_, _>.

With the lambda in the example it is unclear by reading the code what the ? should do. Stop at the first error and return Err? Or should the return value be Result<Vec<_>, _>?

One can use the try_ functions on an iterator.

Considering the author has been using rust for 10 years (if we believe them) I think it's saying something

The problem with .map().collect()? is that it does not short-circuit.

Consider:

  for item in iterable.iter() {
    item.foo()?;
  }

You will exit the loop as soon as there is an error. But with .map().collect(), you iterate over the whole list, and then exit if one of the items yield an error.

EDIT: Thank you for your answers, it seems I was wrong and it does short-cricuit!

Collecting into a result will short circuit.

Realistically, the 'problem' is that many programmers today get scared away when you start mentioning monads or effect systems. Realistically though, the solution is to have first class monads or effect systems in rust and other languages. A lot of language design today is 'wasted' in the sense that we spend time implementing special cases (Promises in javascript, ? syntax in rust, async syntax in rust) without any thought given to the meta problem. In my opinion, the lack of attention to the meta problem is due to programmers being scared of such topics.

Incorrect: collecting to a Result stops on the first error, as documented explicitly in https://doc.rust-lang.org/std/result/enum.Result.html#method....

That's not true: https://play.rust-lang.org/?version=stable&mode=debug&editio...

    let v: Option<Vec<i32>> = (0..5).map(|i| {
        print!("{i} ");
        if i == 3 { None } else { Some(i) }
    }).collect();
    // prints 0 1 2 3

Short-circuit refers to stopping not skipping.

I don’t understand. The example you replied to stopped, not skipped.

that should print 4 and 5 if that was skipping ?

Yeah I read too fast.

One of the issues with type inference, this exact same code does different things depending on whether the result is assigned to `Option<Vec<i32>>` or `Vec<Option<i32>>`

Map and friends are lazy, so the whole chain is run once and in full for each item. Collect will short circuit at the first Err encountered. You can even try it out by using `.inspect()` in the chain to see that the iterations don't go past the first error.

Except it does! https://doc.rust-lang.org/src/core/result.rs.html#2029

Does this early exit on error?

Yes. You can prove it to yourself with this program: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Reply on news.ycombinator.com