I prepared a patch that renames everything as proposed with the
exception of Option's unwrap -> get change here:
https://github.com/Kimundi/rust/commit/752912f75f6334da87a476fffc2475a3dfa5639d
I touches ~ 300 lines, most of them being the unwrap -> get and
unwrap_err -> err_get fallout.
In fact, only a few singular places actually needed to call a `ok()`,
`err()` or `as_ref` adapter at all, most just unwrapped or mapped.
I discovered another issue though: Right now we require a ToStr bound on
Results error type E. Ignoring for a moment that ToStr is on the way
out, the idea behind that bound is that the unwrapping functions could
provide a useful error message in the common "unwrap an Err value" case.
Changing Result to use composition through as_ref() and ok() complicates
that goal:
- The first problem is that ok(self) -> Option<T> throws away the Error
type, which means you'd be only ever be able to see the informative
error message if you use the shorthand get() and err_get() methods,
which leads to inconsistency.
- The second, more interesting problem arises with as_ref. By turning
Result<T, E> into Result<&T, &E>, we changed the self type so that now
an ToStr bound on &E is necessary. This could be solved by a generic
ToStr impl of &T for all T: ToStr, however that could decrease usability
of ToStr, as users might now get seemingly random "&" prefixes all over
the place in their to_str() outputs.
The good news is that those two issues might cancel each other out: If
it gets decided that a composable, Option-API-leveraging interface is
more important for Result than potentially more usable error messages in
case of unwrapping an Err value, then we can just remove the ToStr bound
and provide consistent, if generic, error messages. The patch above
takes that approach for simplicity.
Kimundi
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
