Support piping

[MagicMuscleMan]

collect_as is clearly superior to collect in general. However, collect can easily be used in pipes with iterators due to its single argument method. I'd like to use collect_as in pipes, too, without the need to use lambdas.

I see the following possibilities, e.g. for Tuple

1. add method collect_as(::Type{T}) which returns a callable to be used as
   1:3 |> collect_as(Tuple) .|> println
2. add method collect_as_tuple(iterator) to be used as
   1:3 |> collect_as_tuple .|> println
3. add a new function collect_tuple(iterator) to be used as
   1:3 |> collect_tuple .|> println

I think 1. is the most generic interface, has the advantage that no new export is needed, but blocks the single-argument method for future extensions (although it should be fine, I think).
I like 3. a bit more than 2. due to its brevity, which is nice in pipes, although I admit that 2. is less ambiguous.

[nsajko]

How do you feel about something like Base.Fix1(collect_as, T)?

Theoretically, Base.Fix is not a zero-cost abstraction, meaning that fixing a type T as the argument in Base.Fix (or Base.Fix1, in this case) may incur a run time cost in some cases. For reference: JuliaLang/julia#59619. However I'm just asking if you like the UX of an approach like Base.Fix1(collect_as, some_type)?

[MagicMuscleMan]

I also thought about Base.Fix1, but it's quite verbose. For once, because it's not exported (although I have it exported in my startup.jl, but still when adding it into a file I need to remember that I need to do something about it).

Additionally, the advantage compared to a lambda is small or non-existent as seen when shown below each other (although one might need to add additional parentheses to the lambda).
x -> collect_as(Tuple, x)
Base.Fix1(collect_as, Tuple)

Furthermore Fix1 always has a certain mental load to me, because I always need to think about whether the 1 means that the first argument will be the remaining degree of freedom or whether it will be the argument which is set. I know, the name is clear, but somehow it carries a higher load than when I have a function returning a function or a functor if both just do the right thing (which is obviously also not always the case).

So it is an option, but I would sort it on position 4 or 5 taking the lambda into account.

Maybe I need to pay more attention to how I use the package to get a better feeling what works. Maybe I need to look at it from the Transducers.jl point-of-view and then there might be a totally different answer?

But we can also come from the other angle: Would you see a conflicting use for the single argument method as defined in option 1 above in the future?

[nsajko]

I feel positive about your option 1 above. Will probably add the method you want, but still thinking about it some.