On Saturday, October 10, 2015 02:57:01 Meta via Digitalmars-d-announce wrote: > On Saturday, 10 October 2015 at 02:31:51 UTC, Martin Nowak wrote: > > That's what I meant, weird use-case, at best it's a callback > > better/setter. > > I've never written such code, but even if you would, the 2 > > pairs of parens are only a tiny problem for generic code, > > nothing to warrant the invasive language feature @property is. > > I don't know how much metaprogramming-heavy generic code you've > written, but I can say from first-hand experience that there is > such a thing as Hell, and it is called Optional Parens.
Optional parens definitely do not help with generic code - quite the opposite. In generic code, it needs to be clear whether a symbol is supposed to represent a field or a function. If it's a field, you call it without parens. If it's a function, it has to be called with parens if it's supposed to be possible to have the symbol emulate a function rather than be a function (e.g. be a delegate). We mostly get away with optional parens on function calls in generic code, because it's pretty rare that we write code that's expecting a function and is given a delegate, except in the cases (like predicates) where we clearly expect any kind of callable, and we have to use template wrappers (e.g. std.functional.binary) in those cases in order to make them all act the same and not care about what exactly we're getting. For symbols that are supposed to act like fields, they can't be called with parens in generic code, or they won't work generically, and unlike with symbols that are supposed to act like functions, it's _very_ common to get a mix of variables and functions for the same symbol across different types. So, generic code that uses parens on what is supposed to be a field will work with a function but fail miserably if the type it's given implemented that symbol as a variable. And that's common enough that generic code needs to get it right, whereas it can mostly get away with it with symbols that represent functions simply due to the fact that they're pretty much always implemented as functions. I don't think that there's any question that generic code would be better off if we didn't have optional parens and if functions which used the property syntax weren't allowed to be called with parens. And D programs typically have a lot of generic code. The problem is that when folks are writing code that uses generic functions (rather than necessarily being inside of generic functions), they like to leave off the parens and think that it's ugly to be required to have them. So, we don't have full property enforcement and will never get it. But that same laxity inside of generic code easily leads to compilation failures when properties are used simply because a function will work with parens (be it an @property function or not) whereas variables won't. Hands down, I think that we'd be better off with strict property enhancement due to all of the generic code that we deal with, but that water is long since under the brigde. Instead, we're forever going to be forced to be even more thorough with unit testing in order to make sure that templated functions don't use parens on symbols that are supposed to be properties/fields and to make sure that it does use parens on something that is supposed to be a function. Since, any time we don't do that, we risk making mistakes and writing generic code that doesn't work with all of the types that it's supposed to work with. The only question at this point is whether we can at least get partial property enforcement out of @property and reduce the number of bugs in generic code or whether @property is pretty much just going to be tossed out. - Jonathan M Davis