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@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.