@property needed or not needed?

[Steven Schveighoffer]

On Sat, 01 Dec 2012 20:03:21 -0500, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> I'd _love_ to make it illegal to call non-property functions without  
> parens,
> and there are definitely folks around here who agree with me, including  
> some on
> the Phobos dev team (e.g. Steven has always agreed with me when this has  
> come
> up), but there are enough folks around here here who like to call  
> functions
> without parens - especially with UFCS and templated functions like map or
> filter - that I don't think that that's going to fly at this point.

Oh, shit.  I missed another important @property discussion.

OK, I will say my peace:

The issue I have with not implementing this is takes power away from the  
designer.

There are three intentions when creating a function w/ regards to  
properties:

1. You intend the function to be called without parentheses to clarify it  
is a property.
2. You intend the function to be only called with parentheses to clarify  
it is a function.
3. You don't care whether it's called with parentheses or not, because the  
name of the function is clearly a property or a function.

These distinctions are important because of the human meaning of the  
function.  i.e. x.read() vs. x.read.  The former looks to me like "read  
using x", the latter looks like "is x read."

With @property, the idea was to implement 1 and 2, and leave nothing for  
poor #3.  It's this #3 which throws a big fat wrench into my evil plans.   
Things like map or filter, which clearly aren't properties by their  
name/usage.

I had a compromise that void parameterless functions could be  
unambiguously called without parentheses.  For example, if x.read()  
doesn't return a value, then the statement:

x.read;

Can't really be misinterpreted as "is x read" because the code isn't using  
the (implied) result.

So that is why I always thought, make non-property functions require  
parentheses.

But here we are almost 4? years later and still have the same situation.   
I give.  As long as we can't call arbitrary functions as setters, I think  
the other failures of allowing the choice of removing parentheses are far  
less severe.  At least we get #1.

The proposed DIP does not look bad, I say do it.

-Steve