Spliterators of iterators

[Paul Sandoz]

On Jun 17, 2015, at 8:10 AM, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Tue, Jun 16, 2015 at 1:43 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> It's a subtle area. Certain Spliterator characteristics refer to the (element) source namely, NONULL, IMMUTABLE and CONCURRENT.
> 
>  Yes, it's  subtle.  I went back and studied
> http://download.java.net/jdk9/docs/api/java/util/Spliterator.html#CONCURRENT
> 
> It strongly suggests that CONCURRENT always refers to the original source (top-level Spliterator) while SIZED and IMMUTABLE refer to "this" spliterator.

It's only when CONCURRENT meets IMMUTABLE that the latter can refer to "this" sub-spliterator.  I think it would be misleading to apply this more generally e.g. to sub-spliterators of a say LinkedList.

If a top-level spliterator is IMMUTABLE then it's sub-spliterators should be too, hence the reference to "element source" in it's documentation. There is no such constraint for SIZE, unless SUBSIZED is also reported.


>   Most surprisingly, it suggests that LTQSpliterator.trySplit should return a spliterator that is both CONCURRENT and IMMUTABLE.
> 
> """A top-level Spliterator should not report both CONCURRENT and IMMUTABLE, since they are mutually exclusive. Such a Spliterator is inconsistent and no guarantees can be made about any computation using that Spliterator. Sub-spliterators may report IMMUTABLE if additions or removals to the source are not reflected when traversing."""


Yes, sub-spliterators may additionally report.

I guess i don't have a strong opinion on modifying sub-spliterators of certain concurrent collections to additionally report IMMUTABLE. My inclination is not to bother but i would not strongly object if someone else did :-)

Paul.