<br><br><div class="gmail_quote">On Wed, Apr 27, 2011 at 9:54 AM, Steve Schveighoffer <span dir="ltr"><<a href="mailto:schveiguy@yahoo.com">schveiguy@yahoo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>Given that those arguing against tight semantics likely don't use @property, I think they are not really concerned with the semantics of @property functions, they only care about non-@property functions.  Likely, they would not care whether @property stays or goes, just as long as it doesn't affect how they call non-@property fucntions.  Correct me if I'm wrong, guys.<br>

<font color="#888888"></font><br></blockquote></div><br>Right.  I think @property solves a somewhat important problem by disambiguating the case of returning delegates, etc.  Whether solving this problem is worth the complexity it adds to the language is something I'm neutral on.  Basically, I really don't care what happens with @property as long as designs that rely on non-@property functions behaving as they do currently don't break.  <br>
<br>I wouldn't care if we were only talking about breaking code in trivial ways, but we're talking, as you mention, about breaking existing <b>designs</b>, and designs I happen to like.  I understand you don't like them, but that's not the point.  The point is that we're talking about very non-trivial breakage of existing code, and @property could solve the main problem it was meant to solve without doing so by having loose semantics.  This is what really ticks me off about @property with strict semantics.<br>