Isnt a way for Option to unwrap implicitely when check on error state is not done ? That would make the code less verbose but still allow the dev to check for error if want? Le 7 déc. 2013 01:12, "Gaetan" <gae...@xeberon.net> a écrit :
> I also find the repeatition of unwrap all over the code being quite nasty > > Most of the time the result is just unwrapped without taking into account > the error case, so i think the usage of Option or Result useless. > > I think a good solution exits and can make the code more maintainable, and > easier to read. There should not have all these unwrap (or get) call for > code we know it cannot fails, because the necessary check has been done > earlier. > > I am in favor of two version of the api: from_str which has already done > the unwrap, and a from_str_safe for instance that returns a Result or > option. > > Or perhaps allow the propagation of Option/Result. > Le 7 déc. 2013 01:03, "Daniel Micay" <danielmi...@gmail.com> a écrit : > >> On Fri, Dec 6, 2013 at 7:00 PM, Palmer Cox <palmer...@gmail.com> wrote: >> > Why not use Result instead of Option for these types of things? Result >> is >> > already defined to be able to return error codes using Err. The only >> way to >> > indicate an error when returning an Option is to return None which >> doesn't >> > allow for that. Also, IMO, None doesn't necessarily mean "error" to me. >> Lets >> > say we have a function defined as: >> > >> > fn do_something(value: Option<~str>); >> > >> > It seems like it would be much to easy to accidentally write something >> like: >> > do_something(str::from_utf8(...)) which might result in the error being >> > hidden since do_something might not consider None to be an error input. >> > >> > -Palmer Cox >> >> If there's only one reason it could fail, then `Option` is the >> idiomatic way to report the error case. It's exactly what `Option` is >> used for. A stack trace can report where the error occurred if you >> decide to ignore the error case and use `unwrap` (or `get`, if it's >> renamed). >> _______________________________________________ >> Rust-dev mailing list >> Rust-dev@mozilla.org >> https://mail.mozilla.org/listinfo/rust-dev >> >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
