JuliaCollections
Import Base.Iterators when IterTools is used
If possible it would be nice if Base.Iterators-functions were imported automatically for cleaner code. Since lines like collect(Iterators.flatten(chain(1:9,reverse(11:20),10) would look cleaner if it was just flatten rather than Iterators.flatten.
When people import IterTools it seems to be clear that they intend to use them (alot) or like to go for functional programming and thus simplifying it sounds like a good idea to me.
We'll have to be more careful than that. There would be conflicts. But we should just clear up those conflicts I think.
I think this is a good idea, and that we should also import the documentation for it too.
Then one would only need to look in Itertools, rather than Itertools and Base.Iterators when looking for a particular set of functionality.
Conflicts between Iterators and IterTools were cleared up.
We can do this, but we won't be able to export everything (e.g., we can't export filter as it's different than Base.filter).
It is still desired but noone has gotten round to it. It is a simple but mildly long PR if you are interested
Add to the exports:
export ifilter, # etc
add to the code:
const ifilter = Iterators.filter
#etc
List of all of them is
countfrom
cycle
drop
flatten
partition
product
repeated
rest
take
Working out which should be prefixed with i is the hard part.
Filter definately should.
The others? idk
In my opinion we should either rename as few as necessary (thus only changing filter to ifilter) or switching all functions to a prefix i version, including the functions of IterTools.
Strategy A: Backwards Compatibility first Pro : Full backwards compatibility while the lazy filter function only gets an additional name. Con: Feels inconsistent
Strategy B: Consistency first As for Strategy A but switched and negated. In the long run this might help whenever Julia decides to switch to an Iterator-first or a Materialize-first manner.