Why RichString's conversion methods didn't end-up using Option?

I don't have any insight into the minds of the developers involved. However:

Consider what the usual use would look like for .toInt, if it returned
Option. I think it would be: "123".toInt.get. Probably in 80% of
cases it would be followed by .get, 10% .getOrElse and 10% various
other Option methods.

I think it would harm readability to have all those .gets around.
toInt is probably validly a partial function.

2009/10/9 Trond Olsen :
> Any particular reason why RichString didn't opt for using Option for these
> conversions (toInt, toFloat etc)? Was it performance or maybe Option didn't
> exists? Wouldn't it make sense to remove these sources of exceptions by use
> of Option?
>

On Fri, Oct 09, 2009 at 03:51:25PM +0200, Trond Olsen wrote:
> Any particular reason why RichString didn't opt for using Option for
> these conversions (toInt, toFloat etc)? Was it performance or maybe
> Option didn't exists? Wouldn't it make sense to remove these sources
> of exceptions by use of Option?

http://lampsvn.epfl.ch/trac/scala/ticket/16

(You read that right, 16!)

This ticket contains what is to trac-specializing historians such as
myself one of martin's more infamous comments: "If Java decided against
this, I do not see why Scala should reach a different decision." I like
imagining quoting that back at him in a variety of unrelated contexts,
before the real me says "yes sir!"