<div dir="ltr">I can imagine a situation that we might not want to treat property functions as DATAs simply.<div class="gmail_extra"><br></div><div class="gmail_extra">If you have a struct which have some property functions as members, and you'd want to serialize it:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">struct S {</div><div class="gmail_extra">   int value_;</div><div class="gmail_extra">   @property int value() { return value_; }</div><div class="gmail_extra">}</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">At least, the serialization library should recognize the S.value is a _property function_, not a int DATA.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
Related bugzilla issue I posted:</div><div class="gmail_extra"><a href="http://d.puremagic.com/issues/show_bug.cgi?id=9062">http://d.puremagic.com/issues/show_bug.cgi?id=9062</a> <br><br>Kenji Hara</div><div class="gmail_extra">
<br><div class="gmail_quote">2013/1/25 Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span><br><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 1/24/13 4:56 PM, Adam Wilson wrote:<br>
<blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Simplicity is clearly good, but there's something to be said about<br>
those warts in chained calls. The UFCS-enabled idioms clearly bring a<br>
strong argument to the table, there's no ignoring it.<br>
<br>
Andrei<br>
</blockquote>
<br>
Then @property needs to be fixed such that optional parens don't effect<br>
it one way or the other. Removing the concept of properties and making<br>
functions that look like properties through optional parens is a very<br>
poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA,<br>
and functions do stuff. That statement alone is an excellent argument<br>
for clearly delineating which is which... Properties are not functions.<br>
</blockquote>
<br></div>
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.<br>

<br>
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.<span class=""><font color="#888888"><br>

<br>
<br>
Andrei<br>
</font></span></blockquote></div><br></div></div>