What is the current stage of @property ?

[Jonathan M Davis]

On Wednesday, June 10, 2020 3:41:54 PM MDT H. S. Teoh via Digitalmars-d-learn 
wrote:
> On Wed, Jun 10, 2020 at 08:24:19PM +0000, Vinod K Chandran via Digitalmars-
d-learn wrote:
> > Hi all,
> > I read in an old thread that authors of D wants to eliminate
> > @property. I just roughly read the big thread bu couldn't find a
> > conclusion. After all that thread is a 48 page longer jumbo thread. So
> > out of curiosity, i am asking this. What is the current state of
> > @property ? Is it deprecated ?
>
> It's stuck in limbo, like many things that people just cannot agree on.
> There are a few places where it's needed (like satisfying the range API,
> which implicitly checks for it), but for the most part, you can just
> ignore it, it doesn't really make a big difference.  Life goes on.

Yeah. There was a ton of arguing about what to do with it in the past, with
the intention at one point being that @property functions would always be
called without parens, and all function without @property would always be
called with parens, but there was never full agreement on it, and once UFCS
became widespread, the idea of requiring parens on non- at property functions
became a lot less popular, because many people don't like the idea of having
empty runtime argument parens on a function call after the template argument
parens - e.g. foo.map!(a => a * 42)() vs foo.map!(a => a * 42). Ultimately,
@property was never completed, and it's sort of just lingered on.

As I understand it, @property currently does exactly two things:

1. Become an attribute on the function which affects the mangling and can be
queried my metaprogramming. IIRC, one result of this is that you can't
overload a function that has @property with one that doesn't. Most traits in
Phobos do not check for @property, but it's possible that some do. At one
point, isForwardRange checked for it for save (which never made sense, since
save doesn't act like a property), but that was removed.

2. Screw with the type of the function so that traits will mostly claim that
its type is the return type of the function rather than a function that
returns that type. This can cause some subtle and annoying problems with
metaprogramming.

Now, there is one ambiguity that @property was supposed to solve that was
never solved, and that's a property function that returns a callable. Right
now, you're forced to use double parens (one set being the optional parens,
and the other being the set to call the return value), whereas if it were
truly treated as a property function, then the first set of parens would
call the return value. As such, you can't really have a property function
that returns a callable (whether @property is used or not). So, even if we
were to actually get rid of @property, we might want to keep it for that
case, but since it's never actually be made to fix that case, such a change
would sadly be a breaking change.

As things stand, @property has no real practical purpose but frequently gets
used to indicate that it's the intention of a function's author for it to be
used as if it were a variable. I suspect that it's also frequently
misunderstand that it's required if you want to call a function without
parens. So, you're likely to see @property in quite a lot of D code, but
ultimately, all it's really doing is serving as documentation of the
author's intent and screwing up metaprogramming.

- Jonathan M Davis