Functions Are Asymmetric

Summary

Here are some functions: auto f() -> int; auto g(int) -> int; auto h(int, int) -> int; What they all have in common, structurally, is that they each return one thing. Even though they may take any number of arguments, they must each have one return value. One shall be the number, and the number shall be one. This is true of all functions. (It’s not too important, but here I consider void to be “one thing” as a return type, for reasons which will hopefully become clear. Zero is right out.) Maybe that doesn’t seem strange. It’s just how we’re used to functions working. Ah, those steeped in functional programming might say, but maybe this is the wrong way to look at it. Because if we curry functions and use partial application, we can say that they always have one argument and return one value, and then they are symmetric. Well that’s mathematically true. This is how some languages — like Haskell — work, and they get along fine, having built-in partial application and lots of tools to deal with that view. Most languages — like C++ — don’t have that wealth of tools and it’s more natural to express multiple-argument functions. Especially because we have different tools to deal with variadic functions. Treating functions like they take multiple values is fine. OK, rather than reducing every function to one argument, alternatively we can try to attack this problem by returning multiple values as one, in a tuple (or other product type), and we could make that work. That would be perfectly doable, if tedious. So why bring this up at all? Because the title is missing a word. It should say “Synchronous Functions are Asymmetric”. Because when we move to asynchronous functions, they needn’t be! But implementing them with synchronous functions — as we must — can impose asymmetry. Here are some asynchronous functions analogous to the functions above: auto f = then([] { return 42; }); auto g = then([] (int x) { return x + 1; }); auto h = then( [] (int x, int y) { return x + y; }); ...