Is the -property compiler flag broken/bad idea?

[Jonathan M Davis]

On Wednesday, June 05, 2013 20:09:29 Gary Willoughby wrote:
> I've been using the -property compiler flag when i compile
> programs and thought it was pretty cool but i've recently had a
> conversation with someone who has informed me it's broken and a
> bad idea.

There have been quite a few discussions on properties. I believe that this was 
the last major one:

http://forum.dlang.org/post/kdqrnl$13ft$1@digitalmars.com

You probably don't want to read it. It's huge. I'll try and summarize the 
situation. Historically, in general, if a function had no parameters and 
returned a value, you could call it without parens, and if a function only had 
one parameter, then you could use the = syntax with it. Some folks wanted 
stricter control over that behavior, and it did cause some problems with stuff 
like functions that returned delegates. If foo were a function that returned a 
delegate, and you wanted to call the delegate without assigning it to 
something first, you had to do foo()() instead of foo(). foo and foo() were 
identical. To fix this, @property was introduced.

The idea behind @property was that if you wanted a function to use the 
property syntax, you had to mark it with @property, and functions which didn't 
have @property couldn't use the property syntax. That would be strict 
enforcement of properties. -property was introduced in an effort to sort out 
the compiler logic required for that enforcement and provide a transition 
process. However, that's where the problems begin.

First off, -property was never fully implemented. All it does is scream at you 
if you call a non-property function without parens. It doesn't complain if you 
call a property with parens, which means that it didn't yet solve the delegate 
problem.

Second, a number of people didn't want strict property enforcement. Many of 
them wanted weak property enforcement - specifically they wanted it to be 
enforced that @property functions be called without parens (fixing the delegate 
problem) but that any non- at property function could be called without parens if 
you wanted to (per the original logic for that pre-dated @property and has 
never actually been removed from the language).

Third, some people (like Andrei) never really liked @property in the first 
place for a variety of reasons.

Fourth, with the advent of UFCS, many more people started really wanting to 
leave the parens out, because they don't like it when you have to use parens 
with both the template argument and the function argument when there is no 
function argument. e.g. range.map(a => a * 3)() or range.filter(a => a < 5)(). 
With option parens, you could do range.map(a => a * 3) and range.filter(a => a 
< 5) instead, which many people found to be more aesthically pleasing.

So, property enforcement (which had never been properly implemented even with 
-property let alone as the normal behavior) became increasingly unpopular. And 
at this point, it's crystal clear that optional parens are _not_ going away.

At this point, -property specifically gives an error when optional parens are 
omitted (in fact, that's all it does right now). So, the behavior that it's 
testing for is behavior which has been determined to acceptable if not 
outright desirable, meaning that using -property makes no sense. And I would 
expect it to go away (or at least stop doing anything) in the near future: 
http://d.puremagic.com/issues/show_bug.cgi?id=10143

Now, the exact future for @property isn't entirely clear at the moment, but I 
think that one of three scenarios is likely:

1. It's gotten rid of entirely, in which case we just retain the original 
behavior. And at this point, most people seem to be fine with just putting up 
with the delegate behavior rather than dealing with @property anymore.

2. @property is retained but really only has an effect on getter functions 
which return delegates in order to solve the delegate problem.

3. @property is retained but is only used to define which functions can be used 
as setters (so we have enforcement on setters but not getters). This could be 
combined with #2.

But regardless of what exactly happens, @property will be far more restricted 
than originally planned (if it exists at all), and -property will be gotten 
rid of.

- Jonathan M Davis