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

[Robert Jacques]

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:
>>> need to adopt the inferior C# approach.
>>
>> And there is another problem with the "superior" D approach: a typing
>> mistake in the name of a property might let you not with one property
>> that is r/w, but with two properties to which one is r/o and the other
>> is w/o.
>>
>> More, those functions might be placed several screens far one from the
>> other.
>
> I agree this is an issue. I think it's good language design to avoid
> "long-distance influence" of one declaration against another.
>
> This is a strong argument for keeping @property for write properties.
>
>
> Andrei
>

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.