On 11/02/2013 04:34 PM, Niko Matsakis wrote:
I am generally in favor of this proposal. It seems to be a reasonable
way forward. It is unclear to me how many types would benefit from
this approach of having methods for each variant, but `Result`
certainly does.
With respect to possible confusion between `is_ok()` and `ok()` -- I
think that the presence of a boolean return type should help with
that. (That is, if you write `if foo.ok() { ... }` the compiler will
catch it readily enough)
That's my thinking too, we're not using a statically typed language for
nothing after all.
Some of the methods on `Result`, however, can't be implemented in
terms of this approach. For example, `chain` and `chain_err` really
need to keep the `Result` return type. But I guess that's clear
enough.
Right, `and` and `or` (which is what we call `chain` and `chain_err`
these days) will still need to be implemented on `Result` directly, just
like `map` and `map_err`.
In fact, the only methods that would actually fall away on todays
`Result` would be `expect`, `expect_err`, a lone `get_ref` and the
iterator constructors.
I'll send an mail containing a working patch in a follow up to this thread.
One specific comment on your message:
- There was talk about making `Result` use an `~Error` trait object
instead of a generic type `E`, which could invalidate most of this
email. However, this could also just mean that you usually will see
`Result<T, ~Error>` in the wild, for which this proposal still
applies. Additionally, even if the Pattern becomes useless for
Result, the problem still exists for any other newtype variant
enums, so I'd like to see it get used anyway.
It is not clear to me why moving to a `~Error` object would have
any effect on this proposal. `err()` would just return `Option<~Error>`
in that case, right?
Well, that would still work, that much is true. However the `as_ref` and
`as_mut_ref` adapters might pose some problems.
Worst case we'll need to have `ok_ref`, `ok_mut`, `err_ref` and
`err_mut` adapters instead, which would be unfortunate, but still better
than duplicating all of `Option`s composable API across `Result`.
Kimundi
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
