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

Manu turkeyman at gmail.com
Thu Jan 24 07:45:34 PST 2013


Absolutely agree.

I think it's pretty weak to say @property is a monster/failure, and then
look at C# for instance where it's great.
Finish the deed!

Your set of proposed rules are far more complex and non-uniform... what is
the advantage to that complexity?
On 24 Jan 2013 19:15, "Bernard Helyer" <b.helyer at gmail.com> 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.
>
>
> -Bernard.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130124/747dd213/attachment.html>


More information about the Digitalmars-d mailing list