On 24 August 2011 23:11, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 08/24/2011 06:55 PM, Dave Abrahams wrote:
That's an asymmetry about most currying syntax that I never liked, at least for C++. I suppose when all functions are fully lazy there's no assymmetry, but that's not C++. In C++ we have parens to trigger evaluation. Even in Phoenix, laziness only goes partway: you still need parens to trigger final evaluation.
ML-based languages are not lazy and have had currying for 40 years. Yet the academics behind functional programming, lambda calculus, theorem proving and logic still seem to fancy them a lot.
But ML doesn't have C++ style overloading. Currying certain overloaded functions is ambiguous. Eric's implementation disambiguates by preferring the original function with the least number of arguments, but allows multiple arguments to be passed at once (implicit uncurrying?) so that you can skip over an overload. I don't think the 'academics' would like that much. But regardless of such nit-picking, my issue with currying in C++ is that what we currently consider to be a safe API change (adding an unambiguous overload or giving a parameter a default value) will become a breaking change.