Design for collections upgrades

Pavel Minaev int19h at
Tue Mar 8 15:05:22 PST 2011

On Tue, Mar 8, 2011 at 1:44 PM, Brian Goetz <brian.goetz at> wrote:

> I would agree with this position.  There are pluses and minuses for the
> eager version, but we can't make the default API either lazy or parallel
> - you have to ask for that, and it should be reflected in the (static)
> type system.
How would the (default) eager API look when applied to an Iterable receiver?
i.e. how would it decide the resulting collection type then?

As a side note, if you do decide to have a separate interface solely to
indicate laziness, please do not call it Stream. It's certainly tempting,
but it invites confusion with I/O streams. As noted earlier by Neal, the
correct abstraction for this already exists and is Iterable. If the only
distinction of this type is that it is (potentially) lazily evaluated, then
call it LazyIterable or DeferredIterable.

More information about the lambda-dev mailing list