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