Methods that are undefined for empty collections

i don't see what you can do as a language designer. it's hardly possible
to make sure a list is not empty at compile time without making empty
lists impossible.
of course you could always return either or option, but that would be a
punch in the face of the standard case.
you could also invent a @mightcrash annotation, but what method is 100%
safe? almost none.

Am 21.08.2011 20:54, schrieb Trond Olsen:
> I noticed there are a few new methods named ___Option(), like
> reduceLeft() and reduceRight() for instance. There are a couple of
> others too like min() and max() that aren't. Besides providing updated
> documentation mention the non-empty requirement, are there ways to
> make these methods safer in practical use, like say with Scaladoc
> annotations which can be used as hints in an IDE?

similar to "withDefault" on maps, you could use a trait to override the
unsafe methods with a default behaviour :)

Am 21.08.2011 21:44, schrieb HamsterofDeath:
> i don't see what you can do as a language designer. it's hardly possible
> to make sure a list is not empty at compile time without making empty
> lists impossible.
> of course you could always return either or option, but that would be a
> punch in the face of the standard case.
> you could also invent a @mightcrash annotation, but what method is 100%
> safe? almost none.
>
> Am 21.08.2011 20:54, schrieb Trond Olsen:
>> I noticed there are a few new methods named ___Option(), like
>> reduceLeft() and reduceRight() for instance. There are a couple of
>> others too like min() and max() that aren't. Besides providing updated
>> documentation mention the non-empty requirement, are there ways to
>> make these methods safer in practical use, like say with Scaladoc
>> annotations which can be used as hints in an IDE?
>