@property - take it behind the woodshed and shoot it?

[Jonathan M Davis]

On Friday, January 25, 2013 14:59:58 Andrei Alexandrescu wrote:
> 2. I have tried to add @property appropriately in Phobos, in particular
> for ranges:
> 
> struct SomeRange {
> @property bool empty();
> @property ref T front();
> void popFront();
> }
> 
> There's more "@property" to be seen with "save" and "back". Subjectively
> that just didn't work well for me. It adds clutter to an otherwise
> simple and straightforward API, and penalizes usage for benefits that I
> could never reap. I understand how some people are glad to put that in
> everywhere, and find meaning in requiring parens with popFront and
> popBack but not the others. Yet for me it was liberating (see 1 above
> too) I could just write "r.popFront" without the parens and have it do
> its deed. It is the right semantics for a simple syntax.

That's simply a question of being able to make function calls without parens. 
That's different from the question of properties, much as there may be 
syntactic similarities.

While properties do involve not using parens, there's a lot more to them than 
simply not using parens. A property function is fundamentally different from a 
normal function by its very nature, not just by its call syntax. A property is 
an abstraction for a variable (and therefore should be swappable with a 
variable), whereas a function is explicitly an action. So, regardless of what 
we do with parenless function calls, getting rid of explicit properties will 
have serious side effects.

> 5. This is a matter in which reasonable people may disagree. For better
> or worse Walter and to a lesser extent myself are in the position to
> decide. We're doing the best to gather, mind, and integrate opinions and
> suggestions but clearly no decision that would please everyone. So
> please bear with us. I understand this may be frustrating but the best
> we all can do is think beyond our own preference and on behalf of the
> larger community.

If we throw away @property, then it will be impossible to swap between using
variables and property functions, which is one of the main purposes of
properties. For instance, it should be possible for a range's front to be
variable if that range doesn't need a function for it. There are currently
implementation problems with @property which prevent us from being able to do
that with @property, but they can be fixed. However, without explicit
properties of some kind, it's just not possible. Not only are the semantics
of a property function still too different from a variable (e.g. += doesn't
yet work with a property function), but the issue of parens on property
functions is a problem.

We need to able to make it so that it's illegal to use parens on a property 
function, not only so that you could potentially swap it out for a public 
variable if the function was no longer needed but more importantly so that 
generic APIs (such as ranges) can guarantee that using a variable instead of a 
property function will work (e.g. if you can call front with parens, then 
front can never be an actual variable). And for that, you need explicit 
properties, not just the syntactic sugar of being allowed to drop parens.

Also, too much of this discussion has focused on getters. @property also has a 
large impact with setter properties. Without it, you'll be able to do stuff 
like

range.popFrontN = 7;
"hello".icmp = "world";
"/usr/bin".buildPath = "dmd";

which makes no sense. As long as we have explicit properties, we can restrict 
the setter syntax to functions that are actually properties and could 
conceivably be replaced with variables. Without them, arbitrary functions 
could be set as if they were variables, many (most?) of which would make 
absolutely no sense as variables under any circumstances.

Keeping parenless functions is one thing, but getting rid of explicit 
properties is another thing altogether.

- Jonathan M Davis