@property - take it behind the woodshed and shoot it?
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Thu Jan 24 09:51:32 PST 2013
On 1/24/13 7:13 AM, Bernard Helyer wrote:
> On Thursday, 24 January 2013 at 08:35:01 UTC, Walter Bright wrote:
>> 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.
>>
>> 1. Empty parens are optional. If there is an ambiguity with the return
>> value taking (), the () go on the return value.
>>
>> 2. the:
>> f = g
>> rewrite to:
>> f(g)
>> only happens if f is a function that only has overloads for () and
>> (one argument). No variadics.
>>
>> 3. Parens are required for calling delegates or function pointers.
>>
>> 4. No more @property.
>
> This is lazy design, plain and simple. You say it's turned into
> a monster, but @property, at its core, is simpler than the heuristics
> you've demonstrated here. To my mind, @property, properly implemented
> is simple:
>
> @property functions may be called with no parens or with assignment as
> the singular argument. Non @property functions may not.
>
> There. No complications. The only complications come from D's history.
> And then you want to turn it back? This seems a terrible idea -- the
> deed is done, pull the trigger. Make @property mandatory for property
> functions.
No. The complications come from the fact that (a) nobody could agree
what should be a @property and what shouldn't; (b) @property adds noise
for everybody for the sake of a corner case (functions returning
delegates); (c) the @property discipline failed to align itself in any
way with better code quality.
Andrei
More information about the Digitalmars-d
mailing list