Consider moving function chaining to a sub package

[BooleanCat]

Is your feature request related to a problem? Please describe.

In order to chain functions at the moment, we need to wrap the iterators in this package within a type cast, for examples:

number := iter.Iterator[int](slices.Values([]int{1, 2, 3})).Take(2).Collect()

This was a deliberate decision in order to provide a toolset of iterators that can be used natively with the Go standard library without type casting.

Unfortantely this comes at the expense of making chaining cumbersome.

Describe the solution you'd like

Consider moving the function chaining aspect to a sub package, and provide versions of every iterator that return an Iterator rather than a Seq so that chaning can be used easily. For example:

numbers := iter.Count[int]().Take(5).Collect()

We'd also need to provide wrappers around the standard library functions that return iterators such as slices.Values and maps.All.

I'm open to being convinced that this is not a worthwhile idea.

Provide code snippets to show how this new feature might be used.

See above.

Does this incur a breaking change?

Yes.

Do you intend to build this feature yourself?

Yes.

[BooleanCat]

@jlc-christie I propose renaming the iter package and moving the chainable type out to a subpackage such that usage looks like:

slices.Collect(fn.Take(fn.Count(), 5))
fnx.Count().Take(5).Collect()

The first is fully compatible with the build in iter.Seq types and users can use it freely without worring about type casting the iterators.

If people prefer the ability the chain iterators with the drawback of the type returns by iterators being a wrapper then they can use fnx.

If you can think of better names for the packages I'm all ears.

[BooleanCat]

We could also facilitate easy conversion back to a iter.Seq with fnx.Count().Take(5).Seq()

[BooleanCat]

We settled on calling the packages it and itx.