Alternatively: join((uppercase(x) for x in xs), "") ?

Or as implementation:
join([io, ]f::Function, iter, vargs...) = join([io, ](f(x) for x in iter), vargs...)

Yeah, using generators here seems more composable and general than adding function arguments to everything?

I wholeheartedly disagree. What's the point of first-class functions and other features from functional programming if you don't get to use them? This isn't Python; littering everything with generators does not improve efficiency or readability.

FWIW it is not that obvious what the function argument does, I thought it would decide how to join, with print beeing the default`.

It seems fairly obvious and consistent to me, since other places we allow function arguments, they (almost?) always mean "map this function across the input during the reduction operation."

The other ones are generally reducers of some kind like maximum(transform, collection). This doesn't fit that general pattern at all. Where do we stop? Any function that iterates over anything could potentially apply a transformation first. Should we have reverse(transform, collection) to reverse a collection while also transforming each element?

This doesn't fit that general pattern at all.

I would argue that it does, as it's equivalent to prod, which accepts a function argument.

I've noticed a growing number of these types of "map as you go" methods for functions. I'd raise a couple points:

• Keyword arguments might be less disruptive. (Caveat is the do syntax, but I do wonder if this may be clearer overall, such as join(itr, ""; map = uppercase))
• I feel this pattern indicates a general desire to have lazy map operation or similar, so users can compose two or more very simple functions, e.g. join(mapped(uppercase, itr), "". Note: I'm not sure generator syntax is alwways ideal and that Generatoris always as useful as e.g. aMappedArray` could be).

Such a discussion might deserve it's own issue, I suppose. (Perhaps this has already been discussed somewhere already?)

Yeah, using generators here seems more composable and general than adding function arguments to everything?

I wholeheartedly disagree. What's the point of first-class functions and other features from functional programming if you don't get to use them?

First-class functions allow you to build lazily mapped containers efficiently, which lets us seperate the concerns of the mapping and the joining to two different operations. This seperation of concerns feels like better software engineering to me, rather than having to add the "lazy mapping" comcept to each and every function in Base.

rather than having to add the "lazy mapping" comcept to each and every function in Base.

I don't get why people seem to be taking this addition to that extreme. There is a fairly clear set of functions that should support this, namely reduction operations, which hardly constitutes "every function in Base."