@property needed or not needed?

[Dmitry Olshansky]

11/19/2012 9:58 PM, monarch_dodra пишет:
> On Monday, 19 November 2012 at 17:42:28 UTC, Dmitry Olshansky wrote:
>> 11/19/2012 7:18 PM, monarch_dodra пишет:
>>> On Monday, 19 November 2012 at 14:58:29 UTC, Andrei Alexandrescu wrote:
>>>> On 11/19/12 4:01 AM, monarch_dodra wrote:
>>>>> I kind of agree with Jonathan here. @property really shines when you
>>>>> want to "add" an attribute to a struct.
>>>>
>>>> I kind of agree with him, too, but it would be a mistake to not reckon
>>>> a change in dynamics. UFCS makes all those extra parens just awkward,
>>>> and people will vote with their code regardless whether some
>>>> particular viewpoint from some particular angle considers the approach
>>>> backwards.
>>>>
>>>> Andrei
>>>
>>> One of the things that we may want to take into account, is that
>>> -property prevents any existing function from migrating to/from
>>> property. For example, if we want to make "retro" a property, we can't
>>> without breaking any and all UFCS usage of retro.
>>>
>>
>> The major problem about @property enforcement as it stands is that it
>> breaks the duality of things like retro:
>> a.retro
>> vs
>> retro(a)
>>
>> Both should be allowed as it's a matter of taste that shouldn't be
>> enforced. A lot of new code uses a.retro and a lot of older code uses
>> retro(a).
>>
>> If retro is property then only the first one compiles
>> If retro is a function then only the second one compiles.
>>
>> Which obviously means @property has to be reconsidered.
>
> Hum... Perhaps you meant:
> a.retro
> vs
> a.retro()

This one too.

> Because "retro(a)" works regardless of the property.

Hm.. being a while since I tried to use -property switch. I thought it 
was also disallowed. Not so bad then I guess.

Looking forward to DIP21.


-- 
Dmitry Olshansky