haskell prelude

[David Conrad]

Rejecting it from forEach wouldn't be appropriate, and I guess you wouldn't
even
want to return Long.MAX_VALUE because the stream might actually be finite
after all*, but you might still want to offer an optional warning if
someone uses
count or forEach on a stream not known to be finite.

Not something turned on by default, but a -Xlint:something option. Then
again,
that may not pull its weight.

David

* The implementation of Iterators::count that was in the May 11 build needs
an
overflow check in the loop:

    if (count >= Long.MAX_VALUE - 1) return Long.MAX_VALUE;

But I realize it's early days for the implementation. It is the thought of
counting
all the way up to Long.MAX_VALUE before returning that keeps me awake at
night thinking of InfiniteIterator marker interfaces. :)


On Fri, Jun 22, 2012 at 6:16 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> [O]ne of the things we may do ... is to maintain a set of stream "state"
> bits

to represent interesting properties -- such as elements are sorted,
> elements

are unique, elements are known to be non-null, the size of the stream is

known and finite. ...
>
> ...
>
> We still have to be careful in what directions we define the bits; they
> need to all be

of the form "has known good property" rather than "has dangerous property".
>  That

way, if the pipeline goes through a stage we know nothing about, we can
> clear the

bit and only lose optimizations, rather than make assumptions that might be
> false.

(So "has infinite size" is not as useful as you might think, since if the
> bit "washes off",

we might make the mistake of passing it to forEach.  And "has finite size"
> is not all

that useful, since we wouldn't want to reject a stream from forEach that is
> not known

to be finite, since it might still be finite (and the user might know
> that.))
>
>
>