I can imagine a situation that we might not want to treat property functions as DATAs simply.
If you have a struct which have some property functions as members, and you'd want to serialize it: struct S { int value_; @property int value() { return value_; } } At least, the serialization library should recognize the S.value is a _property function_, not a int DATA. In most case, property functions should be treated as a simple DATA field. but in a few case, it shouldn't. I have thought AddressExpression &func is one of the places. Related bugzilla issue I posted: http://d.puremagic.com/issues/show_bug.cgi?id=9062 Kenji Hara 2013/1/25 Andrei Alexandrescu <seewebsiteforem...@erdani.org> > On 1/24/13 4:56 PM, Adam Wilson wrote: > >> Simplicity is clearly good, but there's something to be said about >>> those warts in chained calls. The UFCS-enabled idioms clearly bring a >>> strong argument to the table, there's no ignoring it. >>> >>> Andrei >>> >> >> Then @property needs to be fixed such that optional parens don't effect >> it one way or the other. Removing the concept of properties and making >> functions that look like properties through optional parens is a very >> poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA, >> and functions do stuff. That statement alone is an excellent argument >> for clearly delineating which is which... Properties are not functions. >> > > I'm not all that convinced, and it's easy to get wedged into a black vs > white position that neglects many subtleties. Properties are DATA, well > except when you need to pass fields by reference etc. at which point the > syntactic glue comes unglued. > > There's been a lot of strong positions years ago about functions vs. > procedures, statements vs. expressions, or even (the glorious 60s!) > in-language I/O primitives vs. I/O as library facilities. Successful > languages managed to obviate such dichotomies. > > > Andrei >