Primitive streams and optional

[Joe Bowbeer]

I can't think of another option, but of those listed I would choose
OptionInt because it appears to be consistent with the parameter type
scheme, right?


On Tue, Nov 20, 2012 at 2:14 PM, Brian Goetz <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"?
>