On Thursday, January 24, 2013 00:34:42 Walter Bright wrote: > This has turned into a monster. We've taken 2 or 3 wrong turns somewhere. > > Perhaps we should revert to a simple set of rules. > > 1. Empty parens are optional. If there is an ambiguity with the return value > taking (), the () go on the return value. > > 2. the: > f = g > rewrite to: > f(g) > only happens if f is a function that only has overloads for () and (one > argument). No variadics. > > 3. Parens are required for calling delegates or function pointers. > > 4. No more @property.
Another issue to consider is enhancements such as http://d.puremagic.com/issues/show_bug.cgi?id=8006 As a property function is supposed to be an abstraction for a variable, and you really should be able to swap out property functions and public variables without breaking code, things like foo.prop += 5; and ++foo.prop; should work. Unfortunately, D's current property implementation is poor enough that that code doesn't currently, but that can be fixed in a backwards- compatible-manner. But implementing something like that becomes more problematic without explicit properties (potentially even dangerous, depending on what ends up happening with those sorts of expressions with non-@property functions which are called without parens). Maybe it could be done, but it seems to me that it's the sort of thing that should be controlled. We don't want lots of voodoo happening with functions called without parens, as we risk getting some nasty bugs when using functions that weren't really meant to be properties. But we _do_ want some of that voodoo with functions that are designed to be properties. So, I really think that we need to have explicit properties, even if we allow paran-less function calls in some other cases. But honestly, I wish that we'd just gone with something closer to what C# did with properties from the get-go. - Jonathan M Davis