On Sat, 01 Dec 2012 20:03:21 -0500, Jonathan M Davis <jmdavisp...@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
