On Thursday, 24 January 2013 at 13:28:48 UTC, Sönke Ludwig wrote:
Am 24.01.2013 09:34, schrieb Walter Bright:
This has turned into a monster. We've taken 2 or 3 wrong turns
somewhere.
Perhaps we should revert to a simple set of rules.
I think Adam D. Ruppe has proposed this in the past and,
although I don't really like omitting
parentheses on ordinary function calls in general (apart from
UFCS template functions), it's clear,
simple and I think everyone could be happy with it:
1. Normal function calls _may_ omit parentheses, but "a = b" is
_not_ interpreted as "a(b)"
2. @property functions can _not_ be called with parentheses and
"a = b" _is_ interpreted as "a(b)"
3. Calling a normal function always returns its return value
This greatly impairs functional style. Just as you demonstrated
nicely with return values, this one cause the same problem with
arguments (either to template or functions).
1. Empty parens are optional. If there is an ambiguity with
the return value taking (), the () go on
the return value.
This sounds like a recipe for disaster. Thinking about generic
code calling functions... it would
surely be very surprising to see how f() sometimes does not
return ReturnType!f, but something
completely different. It would also break all existing code
that currently expects f() to simply
return its return value. More importantly, adding or removing
an opCall or changing the return type
of a function would possibly silently change the meaning of
code that calls the function.
IMO it is also utterly unexpected/counter-intuitive for a
seeming function call not to return its
return value, but call it and return the result.
Great explanation on how it mess up return values when using very
functional style.
