What do you think about implicit unwrap? I don't know if this could be done but I find it pretty elegant.
It's a design choice. For me all API should follow the same pattern, not some returning bare result without failure case, or return a boolean and modify the content of a pointer, or use Result/Option. Most of function look like thing - function definition - check inputs are correct - process with inputs - return a value Most of std/extra methods currently look like: 1 function def 2 ... .unwrap()...unwrap() 3 continue to unwrap(), unwrap() 4 return Ok(...) or Err(..) or return Option while unwrap in part 2 may have sense (check if inputs are correct), they don't have in the third part of the fn. What I really advise is to go to a solution where the developer will avoid each time to call unwrap/get, without checking for the return state because it cost too much. When you call a system api you check for the result because it has great chance to fail, but when you know what you have in input, you call unwrap() without taking care of the failure cases, and if a failure occurs, you can expect things to be in suffisant bad shape to let the task completely fails. Maybe split the methods into two categories: API calls that may fails and return a Result, and obvious convert methods that has no sens to fails once the input has been properly check, so doesn't use Result. But at the end of this discussion, I also strongly advise to write the solution down in a reference page on the wiki, having the current "state of the art" for this matter is extremely important, because the source code has different design choices, with this page everyone will know what is the current best pratice for such function calls. PS: I really like the "?" solution, where func?() returns a Result and func() return the bare result, I find it in the same spirit than fmt!, that makes the language special but in a sexy way :) ----- Gaetan 2013/12/7 spir <[email protected]> > On 12/07/2013 10:53 AM, Simon Sapin wrote: > >> On 07/12/2013 01:07, spir wrote: >> >>> Maybe it's only me, but this not at at all clear to my eyes. My imagined >>> soluton >>> (for a totally different lang) was something like this, on the caller >>> side: >>> >>> ucodes = s.utf8_decode()! // source should be correct, error on >>> failure >>> ucodes = s.utf8_decode()? // logical failure expected, return >>> None or >>> whatnot >>> >> >> >> This is interesting, but I’d like to discuss what to do in this particular >> language, Rust that is trying to go to 1.0 and will probably not accept >> such >> syntax change :) >> > > > You are right, indeed! ;-) > But the issue exists anyway... dunno about solution. In fact we'd ned to > invert the logic: instead of: > x = foo() // Option element wrapping possible result > x = foo().unwrap() // bare result > think: > x = foo().option() // Option element wrapping possible result > x = foo().direct() // bare result > or even > x = foo() // bare result > > Denis > > _______________________________________________ > 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
