Another appeal to fix Function.compose

Dan Smith daniel.smith at
Fri Mar 29 11:26:00 PDT 2013

On Mar 28, 2013, at 5:49 AM, David Holmes <David.Holmes at> wrote:

>> I don't mind this change, so long as there is an equivalent that does
>> the original behaviour that I would see as more natural (again, as a
>> non FP programmer).
> Isn't the original behaviour now g.compose(f) ?

Keep in mind that the difference in your translation from 'f.andThen(g)' to 'g.compose(f)' is more than syntactic -- different typing rules apply to the receiver of a method invocation vs. an argument to an invocation.  So both methods are probably justified.

void test(Function<Integer, String> f) {
  Function<Integer, Integer> f2 = f.andThen(s -> s.length());


void test(Function<Integer, String> f) {
  // this won't compile: Function<Integer, Integer> f2 = (s -> s.length()).compose(f);
  Function<Integer, Integer> f2 = ((Function<Integer, String>) s -> s.length()).compose(f);

Of course, similar use cases could be constructed going in the opposite direction.  It does seem that it's equally reasonable to want to "chain" a function onto another either beforehand ('compose') or after ('andThen').


More information about the lambda-dev mailing list