Primitive streams and optional

[Brian Goetz]

OK, I think we have all the options and combinations of options on the table.

A: OptionalInt min()
B: int min(int defaultValue)
C: int min() throws NSEE

and also a variant

A': Optional<Integer> min()

The realistic choices are: 

1: A only.  In some sense, this is the "obviously right" choice in that it most correctly tracks the desired semantics.  The reason we're even still talking is that people say "Euwwww, boxing!", whether because of actual or perceived performance issues.  So any other choice is a compromise to accomodate annoying realities like "we still care about primitives in 2012."  

2: A and B.  This is most consistent with how we treated reduce() on object streams; the boxing-phobic could provide an explicit seed.  However, it's still pretty smelly in that with reduce, the seed has a mathematically sensible meaning (the zero element of the monoid associated with the operator), whereas for min/max, there is no zero or otherwise universally sensible default value, and users have to pick the lesser of stupid values (and which may well lead to mistakes.)  So really the only reason to support B in addition to A is to allay the boxophobia.  

3: A and C.  I think in this case, C risks being an attractive nuisance, where boxophobes will reach for it and be surprised by the runtime NSEE.  So I don't think it's a great choice.  

B only, or B and C, suffer from the "map.get()" problem, where the user cannot tell the difference between "not there" and "happened to be equal to only value in the stream."  I think we can reject these options out of hand.  

Separately, there is the A vs A' issue (or A'', which would be the merged OptionalNumeric.)



On Nov 21, 2012, at 9:27 AM, Brian Goetz wrote:

>> I prefer the use of Optional<Integer>. I could live, begrudgingly, with OptionalInt, but i don't think there is a strong technical requirement for it.
> 
> The argument against OptionalInt vs Optional<Integer> is basically "OMG, N more classes."  If we did Doug's "Numeric" trick, we could get away with one new OptionalNumeric class.  
> 
>