What's the story with -property?

[Jonathan M Davis via Digitalmars-d]

On Saturday, 27 June 2015 at 22:55:48 UTC, Mike wrote:
> There's a regression involving `-property` at 
> https://issues.dlang.org/show_bug.cgi?id=14564.  In that issue, 
> it's stated by a reputable source that `-property` is going 
> away.
>  It was also stated in IRC that it never worked anyway.
>
> So, what's the story on `-property`? Is it going away?  Is the 
> regression worth investing time in?
>
> There's also a DMD pull request that, unfortunately, was not 
> followed through on: 
> https://github.com/D-Programming-Language/dmd/pull/2305

It was never intended that -property be kept. It was always 
intended to be temporary. The only question at this point is what 
behavior the compiler will have normally.

Originally, property functions were inferred by the language. The 
compiler would treat any function with no arguments as a getter 
property and any function with a single argument as a setter, but 
this isn't particularly principled, and it allowed nonsense like

     writeln = 7;

Also, you have the problem of a getter property which returns a 
delegate. What does this do?

     foo.delegProp();

It just calls delegProp and does nothing with the return value. 
If you want to actually call it, you have to use two sets of 
parens.

    foo.delegProp()();

And that pretty much destroys the ability to have property 
functions which return a delegate or other callable. So, 
@property was proposed to fix these issues. It would be what was 
used to indicate that a function was a property function, and we 
wouldn't have the compiler inferring property functions anymore. 
So, in theory, it would then be illegal to call an @property 
function with parens (thus ensuring that if parens were used, 
they were used on the return value), and it would be illegal to 
call a normal function without parens, since it wasn't a property 
function anymore. However, this was somewhat controversial (with 
some being _very_ much in favor of it and others not being very 
happy about it), and more importantly, it was a breaking change. 
So, when @property was introduced, it didn't do much of anything. 
It was going to at some point, but it didn't then. So, later, in 
order to combat the issue with breaking changes, -property was 
introduced with the idea that it would have property enforcement, 
and we'd have the chance to iron it all out there before making 
the compiler act that way all the time.

However, -property did only partial property enforcement. It just 
made it so that you couldn't call a normal function with parens. 
It did nothing to ensure that an @property function was called 
without parens. And it was never completed, leaving @property as 
doing almost nothing normally and -property not really doing its 
job (@property does affect some aspects of compile-time 
introspection such as typeof but outside of -property, it has 
_no_ effect on how functions are called).

And this controversial issue only got worse when we added UFCS to 
the language rather than just supporting the member call syntax 
with arrays, because then all of a sudden, folks were writing 
code like

     auto foo = range.map!(a => a % 100)();

And they thought that the extra parens on templated functions 
like map were ugly, so people started doing stuff like

     auto foo = range.map!(a => a %100);

So, the idea that enforcing that non-property functions be called 
with parens became less and less popular - and remember that 
that's the only thing that -property actually checks right now. 
Also, arguments on @property never went anywhere useful, because 
there were folks on both sides of the argument (and several spots 
in between), and many felt very strongly on the issue. In 
addition, Andrei has never liked the idea of @property, so 
nothing really ever happened, and we've gotten less and less 
willing to break code as time has gone on, meaning that the 
willingness to switch to full property enforcement (or even 
partial property enforcement) has decreased as well.

The _most_ that we could get at this point would be to have it 
enforced that @property functions be called without parens 
without requiring that non-property functions be called with 
parens (UFCS has simply made it too popular to leave off the 
parens) and possibly requiring that @property be used in order to 
use the property setter syntax. However, even that would break 
code, so it's questionable as to whether that would occur. It's 
almost a guarantee that @property will at some point affect 
functions which return callables and interpret their first set of 
parens as calling their return value, since without that, we 
can't treat functions which return callables as property 
functions, but beyond that, it's an open question as to whether 
any kind of property enforcement will ever be in place.

Regardless, as it's a guarantee at this point that we're not 
going to require parens on normal functions, -property is 
currently enforcing something that we don't intend to ever 
enforce. So, there is no reason to ever use it. We would have 
dropped it anyway once it was fully ironed out, and we were 
migrating its behavior into the language proper, but at this 
point, pretty much the only reasons that it exists are to avoid 
breaking the build process of anyone using it, and because no one 
has removed it. Really, it should be changed to do nothing 
(except maybe print a message about going away) as the initial 
change so that it doesn't break anyone's build process, and we 
don't have to support it.

We _were_ building Phobos with it to avoid breaking folks code, 
but clearly, we stopped, because we have that regression now. So, 
I think that we need to either build Phobos with -property again 
and fix the regression (so that we don't break other people's 
code), or we need to change the compiler so that -property does 
nothing except print a message that the -property flag has been 
deprecated and does nothing.

- Jonathan M Davis