@property - take it behind the woodshed and shoot it?

[deadalnix]

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.