[rust-dev] Rust lightning talk at JavaZone 2012
steven099 at gmail.com
Fri Aug 24 13:20:42 PDT 2012
On Friday, August 24, 2012, Nathan wrote:
> > 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?
> > course that probably does not apply where an error or failure might
> > (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
> be forced to deal with that case.
That's what a `result` is for.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev