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