[rust-dev] Rust lightning talk at JavaZone 2012

Steven Blenkinsop steven099 at gmail.com
Fri Aug 24 13:20:42 PDT 2012


On Friday, August 24, 2012, Nathan wrote:

> On Fri, Aug 24, 2012 at 10:13 AM, Ziad Hatahet <hatahet at gmail.com<javascript:;>>
> wrote:
> > On Thu, Aug 23, 2012 at 8:16 PM, Jeffery Olson <olson.jeffery at gmail.com<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20120824/9ff3beb2/attachment.html>


More information about the Rust-dev mailing list