On Thursday, October 08, 2015 15:00:15 Martin Nowak via Digitalmars-d-announce wrote: > On Thursday, 8 October 2015 at 12:48:48 UTC, Adam D. Ruppe wrote: > > On Thursday, 8 October 2015 at 04:14:59 UTC, extrawurst wrote: > >> Does that mean @property has no effect anymore ? > > > > @property never actually worked anyway. It is still my hope > > that it will be correctly implemented some day though > > I think http://wiki.dlang.org/DIP23 reflects the most accurate > roadmap for @property, basically being permissive w.r.t. parens. > And who really cares whether it's rng.popFront or rng.popFront()?
What's problematic with regards to requiring parens or not is when the symbol _can't_ be called with parens. So, whether popFront is called with parens or not realistically doesn't matter, because it's going to be a function (theoretically, it could be a member variable that implements opCall, but that's so unlikely that there really is no need to worry about it IMHO). However, it _does_ matter whether something that's intended to be used as a property or not is called with parens. Code which uses parens on save or front is not going to work with all ranges, because they're not always functions. So - at least in templated code - it needs to be clear when a symbol is treated as a property, and it cannot be called with parens if it is supposed to be a property. Enforcing that @property is called without parens wouldn't entirely fix that problem, but it would help catch cases where someone actually used parens when they shouldn't have. Regardless, what we pretty much need to do with @property at some point is make is that it's used to make it so that a single pair of parens operate on the return value rather than the function even if we don't do anything else with @property - otherwise properties which are delegates or other callables aren't possible. Having DIP 23 be implemented would be great though. - Jonathan M Davis