<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 4, 2013 at 2:23 AM, Dicebot <span dir="ltr"><<a href="mailto:public@dicebot.lv" target="_blank">public@dicebot.lv</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Wednesday, 4 September 2013 at 02:26:27 UTC, Timothee Cour wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
that's the whole point, it allows to transparently replace a field access<br>
by a property function call without breaking client code. How else would<br>
you do that?<br>
</blockquote>
<br></div>
You can't replace field access with function call transparently if it has side effects. In the end breakage may be even worse. For me only replacing @property fields with @property methods makes sense (with former prohibited to be taken address of and latter forced to be weakly pure).'<br>
</blockquote><div><br></div>IIRC, &foo.x with x a property should take address of return value of x(), which will either fail to compile or do the right thing if it returns a lvalue. So there's no undefined behavior as far as taking address of is concerned when replacing field by property. </div>
<div class="gmail_quote"><br></div><div class="gmail_quote">As for side effects, this is the reason one would go from field access to property, eg populating some data upon 1st access to a field x. Sure it can be misused, but I haven't seen a case in practice where it is misused.<br>
<div class="gmail_extra"><br><br></div><div> </div></div><br></div></div>