Ah, true enough. I think you were correct, and I misread the original
email. `swap(&mut map, &mut and_then)` and fmap <-> monadic bind in my
reponse.
Huon
On 10/02/14 23:00, Sergei Maximov wrote:
I believe it depends on what return type `.method` has, but I got your
point.
02/10/2014 10:50 PM, Huon Wilson пишет:
It's actually Haskell's fmap, which we have in the form of .map for
both Option[1] and Result[2], e.g. the proposed expr->method() is the
same as expr.map(|x| x.method()) (which is still quite verbose).
Monadic bind comes in the form of the .and_then methods (which both
Option and Result have).
[1]:
http://static.rust-lang.org/doc/master/std/option/enum.Option.html#method.map
[2]:
http://static.rust-lang.org/doc/master/std/result/enum.Result.html#method.map
Huon
On 10/02/14 22:45, Sergei Maximov wrote:
It looks very similar to Haskell's monadic bind operator (>>=) at
first glance.
02/10/2014 10:40 PM, Armin Ronacher пишет:
Hi,
I was playing around with the new IO system a lot and got some very
high level feedback on that. Currently the IoResult objects
implement a few traits to pass through to the included success
value and to dispatch method calls.
That's nice but it means that from looking at the code you can
easily miss that a result is involved and if you add methods you
need to add manual proxy methods on the result.
At the end of the day the only thing you actually need to pass
through is the error. So I would propose a new operator "->" that
acts as a "resolve deref" operator. It would be operating on the
"Some" part of an Option and the "Ok" part of a result and pass
through the errors unchanged:
So essentially this:
let rv = match expr() {
Ok(tmp) => tmp.method(),
err => err,
};
Would be equivalent to:
let rv = expr->method();
Likewise for options:
let rv = match expr {
Some(tmp) => tmp.method(),
None => None,
}
Would likewise be equivalent to:
let rv = expr->method();
As a result you could only ever call this on things that return
results/options themselves.
Annoyingly enough this also means that the results need to be
compatible which is still a problem. The example there would be an
IO trait that is implemented by another system that also has its
own error cases. Case in point: SSL wrapping that wants to fail
with SSL errors in addition to IO errors. I fail to understand at
the moment how library authors are supposed to deal with this.
Thoughts on this? Am I missing something entirely?
Regards,
Armin
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
