Iterator.continually(1).toIterable eagerly evaluated in Scala 2.13

[marko-asplund]

Iterator.continually(1).toIterable seems to be lazily evaluated in Scala 2.12, but eagerly in Scala 2.13.

reproduction steps

With 2.12 the following returns an Iterable[Int] backed by Stream

scala> Iterator.continually(1).toIterable
res0: Iterable[Int] = Stream(1, ?)

problem

With 2.13.3 the iterator seems to get evaluated eagerly:

scala> Iterator.continually(1).toIterable
                               ^
       warning: method toIterable in class IterableOnceExtensionMethods is deprecated (since 2.13.0): Use .iterator.to(Iterable)
// evaluation keeps running

the same result with the following except without the compiler warning

scala> Iterator.continually(1).to(Iterable)
// evaluation keeps running

I'd expect similar behaviour as with Scala 2.12.

[NthPortal]

fwiw, Iterator.continually(1).to[Iterable], which is slightly closer/more equivalent to Iterator.continually(1).to(Iterable), does evaluate to an eager collection in 2.12 (and hangs)

[NthPortal]

workaround (solution?): use Iterator.continually(1).to(LazyList), or better yet, LazyList.continually(1)

[marko-asplund]

Thanks for the reply @NthPortal ! 👍

I did implement the former workaround when I figured out what was causing the hang, so this isn't a problem for us right now.

However, as it was pretty hard to find the bit that caused the hang, I suspect other people might also get bit by this. So, I was thinking is there something that could be done to help people migrating to Scala 2.13 avoid this in terms of documentation and/or code changes? I went through the 2.13 collections changes doc as well as release notes, but couldn't find (or maybe just failed to connect) any references to this change in behaviour.

[NthPortal]

the solution may be for someone to add a note to https://github.com/scala/docs.scala-lang/blob/master/_overviews/core/collections-migration-213.md - not sure if there should be a tweak to scalafix rules as well? cc @julienrf

[joshlemer]

There's also View.fromIteratorProvider(() => Iterator.continually(1))

[dwijnand]

fwiw, Iterator.continually(1).to[Iterable], which is slightly closer/more equivalent to Iterator.continually(1).to(Iterable), does evaluate to an eager collection in 2.12 (and hangs)

Sure, but Iterator.continually(1).toIterable still exists, and (IMO) the change is a regression.

Am I missing something? Does anything prevent us from fixing this?

[joshlemer]

There is a convention in 2.13 that all the .toX methods are strict, and where X is abstract (toSet, toSeq, toMap, toIterable) construct that abstract collection's default implementation. So toIterable constructs a List because that's its default implementation. It would be a breaking of convention in two ways to have Iterator.continually(1).toIterable create a View or LazyList on account of both the default-collection convention and the strictness convention.

[dwijnand]

Ah, I see! So, yeah as Princess says: add a note to the migration to close this.

[martijnhoekstra]

Is that convention worth refining, to e.g. if the X in toX can be either eager or lazy, it will be the default eager implementation if the source was eager, and lazy if the source was lazy? Part of me wants to say that if you wanted something lazy you should have been clearer about what you wanted, but another part of me has a hard time believing there are people who are helped by Iterator#toIterable being eager.

[NthPortal]

I think the convention for to(X)/toX is that if the collection is already an X, it returns the collection unchanged, but if not, it creates the default kind of X

[NthPortal]

@dwijnand I'm becoming increasingly convinced by your argument that lazy and strict collections should be in separate hierarchies