On Fri, Aug 24, 2012 at 10:13 AM, Ziad Hatahet <[email protected]> wrote: > On Thu, Aug 23, 2012 at 8:16 PM, Jeffery Olson <[email protected]> > 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. > Thanks, > > -- > Ziad > > Nathan > _______________________________________________ > 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
