Primitive streams and optional

[Brian Goetz]

That's an option too, thanks for reminding me.

Let me turn that one around.  Would you be happy with a single min(def) 
method that made you choose a default value always?  Or would you find 
it annoying and want something else too, for the cases when you know 
there are elements?

Would you spend any time wondering what the default value should be?

Would you worry about how to distinguish between the case that it 
returns the default value and the case when the default value actually 
was the minimum (a la map.get())?

I would guess that if you had min(defVal) you'd also want another 
version (throwing? optional?) for the cases when some of the above 
bother you?



On 11/20/2012 5:43 PM, Tim Peierls wrote:
> What happened to min(int defval)? That way the library doesn't have to
> decide on a good default, but the user can.
>
> --tim
>
> On Tue, Nov 20, 2012 at 5:14 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     We're working through implementing the primitive specialization of
>     streams now.  So far, its pretty straightforward; many of the ops on
>     reference streams have an obvious analogue (e.g., filter, map,
>     forEach), and many are just not applicable (e.g., into, since there
>     are no primitive collections.)  There are also a number of
>     additional methods that make sense on primitive streams, such as
>     sum().  (You can see the work in progress in the lambda repo.)
>
>     The tricky ones are the ones that return some sort of Optional.  For
>     sum() there is an obvious value to return if there are no elements
>     in the stream (zero), but for min/max/average, it would require more
>     distortion to avoid optionality.  We can't expect users to know a
>     priori whether the stream is empty.  Example:
>
>     int firstOrderNumber
>        customers.flatMap(c -> /* c.orders */)
>                 .map(o -> o.getOrderId())
>                 .min();
>
>     The options are:
>
>       - throw NSEE
>       - make up a bad default (e.g., MAX_VALUE for min)
>       - return an Optional<Integer>
>       - return an OptionalInt
>
>     The first two are pretty bad, and are asymmetric to the reference
>     streams.  Creating N new OptionalXxx classes is kind of annoying and
>     bloaty.  (There's an argument to be made for "Well, we're boxing
>     once at the end anyway, boxing twice with Optional<Integer> isn't
>     terrible.") Though I suspect that will be an ongoing irritant.  Are
>     there other "options"?
>
>