Stream constructors for stream(Iterator) in StreamSupport?

[Brian Goetz]

> That's a great taxonomy of ways to make a stream, but the division of
> static factory methods into Streams and StreamSupport wasn't, as I
> understood it, along those lines. It was about keeping concepts that
> most users aren't going to want to mess with (i.e., Spliterator) out of
> their line of sight.

That was indeed part of it.  But the other part of it was guiding them 
away from low-level tools they might mistakenly (mis)use because we'd 
not sufficiently labeled things into bins of "for users" and "for 
library writers."  I still think stream-from-iterator is low-level, 
because it involves choosing things like stream flags (and doing it 
wrong will have bad results.)

> If all you have is an Iterator, you don't want have to go down into the
> basement to get something that turns it into a Stream. Put those
> tradeoffs on the packaging but leave the package in the kitchen.

So, the tension here is:
  - helping the poor users for whom all they can get is an Iterator, and 
they want a stream;
  - avoiding the moral hazard of encouraging people to think that 
Iterator is actually a *good* way to make a stream (which might even 
encourage them to write more Iterators!)  I want them to think is 
"Iterator is the last possible resort for making a stream, including a 
number of resorts that I should learn about first before writing an 
Iterator."

The current status quo is either better or worse in this, depending on 
which of the two above forces you are more compelled by.  The way to 
make a Stream from an iterator currently is:

   Streams.stream(Spliterators.spliteratorUnknownSize(iterator, flags));
   Streams.stream(Spliterators.spliterator(iterator, size, flags));

Which do the job but suffer from poor discoverability.  On the other 
hand, it has none of the moral hazard -- its pretty clear you're nailing 
bags on bags, and I don't think this status quo is so awful.


Another direction (as discussed previously without convergence) would be 
to augment Iterable with a stream() method.  This helps users of 
non-Collection Iterable classes, but still has some of the moral hazard 
as it does not put enough pressure on writers of Iterable classes to 
write better stream() implementations.