On 12/06/2013 12:41 PM, Simon Sapin wrote:
We have some functions and methods such as
[std::str::from_utf8](http://static.rust-lang.org/doc/master/std/str/fn.from_utf8.html)
that may succeed and give a result, or fail when the input is invalid.
1. Sometimes we assume the input is valid and don’t want to deal with
the error case. Task failure works nicely.
2. Sometimes we do want to do something different on invalid input, so
returning an `Option<T>` works best.
And so we end up with both `from_utf8` and `from_utf8`. This
particular case is worse because we also have `from_utf8_owned` and
`from_utf8_owned_opt`, to cover everything.
Multiplying names like this is just not good design. I’d like to
reduce this pattern.
Getting behavior 1. when you have 2. is easy: just call `.unwrap()` on
the Option. I think we should rename every `foo_opt()` function or
method to just `foo`, remove the old `foo()` behavior, and tell people
(through documentation) to use `foo().unwrap()` if they want it back?
The downsides are that unwrap is more verbose and gives less helpful
error messages on task failure. But I think it’s worth it.
What do you think?
(PS: I’m guilty of making this worse in #10828, but I’d like to
discuss this before sending pull requests with invasive API changes.)
I agree in this case (and probably a lot of cases), especially since
this is a relatively uncommon operation and since (I think) we're
prefering 'get' to 'unwrap' and that's even shorter.
There are some cases where I think failure is the right option by
default though; in particular I was worried you were going to bring up
the 'send' and 'recv' methods on channels which fail when disconnected.
In this case I think it won't be common to handle the failure since it
indicates some logic error, and these are very common operations.
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
