Import Base.Iterators when IterTools is used

[Aaron Matthis]

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.

[Alex Arslan]

We can probably do this with @reexport using Base.Iterators.

[Eric Davies]

We'll have to be more careful than that. There would be conflicts. But we should just clear up those conflicts I think.

[Frames White]

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.

[Eric Davies]

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).

[Frames White]

Can we export those things as ifilter to match to imap etc?

[Aaron Matthis]

Are there any news on this?

[Frames White]

It is still desired but noone has gotten round to it.
It is a simple but mildly long PR if you are interested

[Aaron Matthis]

@oxinabox what would I have to change?

[Frames White]

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

[Aaron Matthis]

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.