On Friday, August 24, 2012, Nathan wrote: > On Fri, Aug 24, 2012 at 10:13 AM, Ziad Hatahet > <[email protected]<javascript:;>> > wrote: > > On Thu, Aug 23, 2012 at 8:16 PM, Jeffery Olson > > <[email protected]<javascript:;> > > > > wrote: > >> > >> > >> And, to be fair, another major plank of the linked post was that > >> Option-style library APIs aren't ubiquitous even in Scala, and > >> certainly not in the larger Java Class Library. This is not true for > >> Rust, where Options<T> (or Result<T, U>)-style APIs exist > >> idiomatically through the libraries ... > > > > > > I am still new to using a language with an Option type (I come from an > > imperative language background,) but wouldn't it be preferable to try to > > mitigate the number of calls that return an Option type as opposed to > > returning an actual reference as references cannot be null/nil in Rust? > Of > > course that probably does not apply where an error or failure might > happen > > (such as IO). > > > > I believe you will find this just "naturally" happens: > > If you're writing code that is intended to produce a value, but you > find there are cases where it cannot, then perhaps option<T> would > make that explicit and type safe for that code and the caller. There > might be other alternative approaches, but hopefully the type system > forces you to deal with the case. option<T> is a way to pass the buck > to the caller, *except* it is explicit (unlike everything-may-be-null > languages where it is effectively implicit). > > If on the other hand, you're writing code and see that in every case > it has a concrete value, then there's no need for option<T>. I think > you'll find that it is natural to drop the type from option<T> in this > case to T when writing new code, because it's simply less effort for > the benefit of fewer cases to produce and deal with. > > At first it may seem cumbersome if you are *refactoring* an API and > change a T to and option<T>, but if you think about it, in an > everything-may-be-null language where you do *not* have to refactor, > you've just introduced many potential bugs without realizing it. > Going the other way, where you refactor an option<T> to a T, you'll > find that you just end up deleting a bunch of now unused code. And > what is more rewarding than deleting code? > > > One last point about runtime errors: I'm not familiar with how rust > handles these, but I believe it would require work and also lead to > poor apis if runtime errors are translated into none options. This > would be akin to swallowing an exception and returning null in a > language like Java/python/javascript, except in rust the caller would > be forced to deal with that case. >
That's what a `result` is for. http://dl.rust-lang.org/doc/core/result.html
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
