Do we want functions to act as properties, or merely omit parens for ufcs/chaining?

[eles]

On Tuesday, 29 January 2013 at 12:18:56 UTC, jerro wrote:
>> What do you eran from that? Sparing "value" as a reusable 
>> identifier?
>
> Not using a magic identifier, which makes the code clearer.

Yes. What about removing $ in array context? That makes it a very 
magic identifier.

OK: use "$" instead of "value". It is magic already.

> Nothing is stopping you from keeping the getter and setter 
> together.

The problem is that nobody enforces you. Nobody is stopping you 
from writing corect code, I can swear that. Still, bugs exist. 
And in your code, too.

> So you are assuming that having a special syntax for defining 
> properties has some psychological effect on programmers that 
> results in proper usage of properties, and that the lack of 
> such syntax in D is the main reason for improper property usage.

I think it will make things clearer for them: a lot of debate was 
needed just to make clear that UFCS/optional_parens and @property 
are orthogonal issues. Do you think that confusion in the 
beginning had nothing to do with the F meaning... FUNCTION?

> I disagree. I think that the main reason @property is currently 
> overused in D  is that people were under the impression that 
> paren-less  calls will only be supported for @property 
> functions in the future. So if people wanted some of their 
> functions to be callable without parens (and some people do 
> want that), they actually had an incentive to make them 
> @property, even if they weren't logically properties.

You see: optional parens mean function, @property means property. 
The confusion that you spot is exactly the confusion that is 
rooted into that mix of properties and functions.