@property needed or not needed?

[monarch_dodra]

On Monday, 19 November 2012 at 08:45:03 UTC, thedeemon wrote:
> On Monday, 19 November 2012 at 08:23:43 UTC, Jonathan M Davis 
> wrote:
>> On Monday, November 19, 2012 09:16:29 Rob T wrote:
>>> My guess is that if @property gets enforced, we'll see a lot 
>>> of
>>> functions with empty parameter lists being defined as 
>>> @property
>>> for the sole reason to get rid of having to type in the ().
>>
>> Which completely violates the concept of a property in the 
>> first place. It's
>> intended to be an abstraction for a variable. Using @property 
>> just to get rid
>> of parens would be like naming types with verbs instead of 
>> nouns. It's
>> completely backwards.
>>
>> - Jonathan M Davis
>
> I very much like the combination of UFCS, ranges and 
> parens-free style which allows writing code like
>
> iota(0, 
> 1000000).map!(to!string).retro.take(50).retro[10].writeln;
>
> So I like Andrei's idea to force @property only for those 
> functions where it's absolutely necessary to fight ambiguity.

I kind of agree with Jonathan here. @property really shines when 
you want to "add" an attribute to a struct. array "front", for 
example, is a perfect example of this. RefCounted's "payload" 
(IMO), is also a good example.

*Functions* that do actual operations, in particular, "retro", 
IMO, should not be properties.

"byLines", for example, is a member function, and not property. 
How is:
r.retro;
any better than
r.byLines()
?

At best, it makes it look like r has a built-in retro attribute, 
which is miss-leading.

--------
I'll admit I thought too it would be "convenient" to write 
".retro" without the parens, but let's face it, that'd be 
incorrect usage...