On Thursday, January 24, 2013 22:24:58 Adam D. Ruppe wrote: > On Thursday, 24 January 2013 at 21:09:39 UTC, Adam Wilson wrote: > > The problem with @property isn't @property, it's D's > > insistence on optional parens. > > No, this isn't a problem; function call syntax has nothing > whatsoever to do with @property because a property is NOT > logically a function!
D's insistance on optional parens _does_ cause problems with functions that return delegates, but @property itself isn't really affected by optional parens save for the visual ambiguity caused by optional parens. > This is so important: a property is supposed to be > indistinguishable from a data member. That's the fundamental > definition. It should be fully interchangeable for a plain data > member. > > In other words, as far as the user is concerned, a property *is* > a data member, NOT a function! > > If functions have optional parens, that changes nothing about how > you access data members.... and since properties are data > members, it changes absolutely nothing about them either. > > If we required data to be accessed with foo->bar and methods to > be called [foo:bar].... a property would be accessed foo->bar. > The method syntax is irrelevant. > > That the property is implemented with a function call should not > be known to the user code. This should probably be emphasized more. A property is an abstraction for a variable and how it's implemented should be irrelevant to the caller. Ideally, it would even be irrelevant whether it's a variable or a property function (though making that the case would require both implementing http://d.puremagic.com/issues/show_bug.cgi?id=8006 and providing a way to mark variables such that they're treated as rvalues rather than lvalues; otherwise, it's still possible to break code when turning a variable into a property function). And we can (and should) implement @property in a way that deals with properties properly regardless of what we do with parenless function calls. - Jonathan M Davis
