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-@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
