I guess it depends how and whether one attempts to abstract the idea.
After thinking it through a bit more, I think that there is a natural interpretation of implicit that applies to anything but it is not identical to the idea in implicit functions, so it is an awkward fit to extend it in the way I was thinking. In particular, conflating an implicit (function from arguments to result) and a function from (implicit arguments) to result seems, on further reflection, like a dangerous idea.
If you use an implicit-argument function as a return value, you can consider it either of two ways:
- It is a formalism that expresses your intent to require an implicit argument, or
- It is an actual object that is created that evaluates when an implicit argument is available
If the latter, then I worry about the performance hit; this is definitely not a zero-cost abstraction if you’re adding the creation of an ImplicitFunction object to every method call. If the former, then I don’t think we’re necessarily prevented from coming up with other low-boilerplate syntax to express the intent when what you really mean is “I don’t care how you do it, just carry along these implicit values” not “I really want a function that takes implicit arguments”. Especially if you tackle the group-of-implicits problem and have an ImplicitTuple3 etc. that is isomorphic to a parameter block of three implicits (and then ImplicitFunction2[A, B, Z] would have a natural relationship with ImplicitTuple2[A, B] => Z).
It seems like implicit tupling is slightly more general than implicit functions in that implicit tuples allow one to talk in a generic way about groups of implicit parameters distinct from what you might use them for, whereas implicit functions require you to have a transformation in mind.