Do we want functions to act as properties, or merely omit parens for ufcs/chaining?

[eles]

On Wednesday, 30 January 2013 at 01:59:52 UTC, Robert Jacques 
wrote:
> On Tue, 29 Jan 2013 09:38:57 -0600, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> On 1/29/13 6:33 AM, eles wrote:
>>> On Tuesday, 29 January 2013 at 11:13:19 UTC, jerro wrote:
>
> How so?
> The op's argument is against having separate function 
> declarations ala D, and for a joint getter/setter syntax. i.e.
>
> foo { get; set; }
> //   vs
> int foo() { return 5; }
> void fou(int x) {}
>
> Because, as illustrated above, the two function names might 
> accidentally be different. As the functions, like all 
> overloads, should be 1 code-fold apart, the actual severity of 
> the bug is the same as accidentally changing the name of an 
> overloaded function during initial coding or during a refactor. 
> Which is neither for nor against @property, but advocating new 
> syntax and keywords for defining properties.

He means that in the context where you cannot have write-only 
properties. So, you have to have at least the getter. Imposing 
@property on the setter means that a getter with the same name is 
needed. This lowers the probability of a typo, since a @property 
fou() will be caught by the compiler as having no getter 
counterpart.

Sure enough, this does not prevent having two getters for foo and 
fou properties, then mistakenly writing the setter for fou while 
intenfing to write the setter for foo.