To me, what you are trying to achieve is a kind of list comprehension. Using you example, with the same function names, here is the corresponding code in Haskell:

[code]
[ f3 x | a <- map f1 [1, 2, 3]
, b <- map f1 [3, 4, 5]
, x <- f2 a b]
[/code]

If you now look at the post from Eric Niebler I linked in my previous comment (http://ericniebler.com/2014/04/27/range-comprehensions/), you will see how to translate such a comprehension from Haskell in C++. It is a really good read, and it will answer your question.

Ok, thanks Quentin for giving your feedback, it’s really helpful. I’d like to benefit from your experience in functional programming as I’ve done quite a few times in the past 🙂

I’ve replaced flatten with join in the post as you suggested. I had missed this adaptor in the range library and it’s exactly what I was looking for, so that’s cool.

In our case, we’d need a functor for functions taking 1 argument, and applicatives for several arguments right? In which case it’s applicative for the general case as you say, and I’ll update the legal note 🙂

I’m not sure how to write make_multiple with just transform and join, as you suggest. Would you have a snippet to illustrate?

Taking a step back over the post, here are its three components:
1) Drawing ideas from FP
2) Implementing them with ranges
3) And the goal is to provide an interface to adapt a plain function to multiple parameters contexts.
You’ve given you’re detailled feedback on 1) and 2), for which I’m grateful. Do you have an opinion on 3)? I’d be interested to hear it.

First, you do not need flatten. There is a view::join which, given a range of range, flattens them into one range. You should check https://ericniebler.github.io/range-v3/index.html#range-views. It is well written, and there are not that many views anyway.

Second (and since you mentioned functional aficionados and playing with functional terms), you are mixing functional concepts: applying a function to all combinations of elements does not require a Monad and not a Function either, it requires an Applicative.

Now, to get a Monad, you need to have either (>>=) or join (preferably join in this case). And so range-v3 library is already designed to be a Monad. To get back (>>=), you just need view::transform and view::join chained together.

So there is no need for the cartesian_product either.

Finally, it seems to me all these posts are about building a « vector comprehension », but doing it wrong (flatten is not lazy and there are plenty of accidental complexity), because of a lack of understanding of Monads and knowledge of range-v3.

For an example of doing « range comprehension » right instead, I encourage the reader to refer to this article of Eric Niebler: http://ericniebler.com/2014/04/27/range-comprehensions/.