<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 8, 2010, at 2:16 PM, John McCall wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 8, 2010, at 1:47 PM, Douglas Gregor wrote:</div><blockquote type="cite"><div>On Dec 8, 2010, at 11:53 AM, Eric Niebler <<a href="mailto:eric@boostpro.com">eric@boostpro.com</a>> wrote:<font class="Apple-style-span" color="#006312"><br></font></div></blockquote><div><br></div>I'm a little worried about adopting our current representation for a C++-oriented feature. Presumably we'd need to allow filling in default arguments, etc., plus a wide range of stuff that we </div></div></blockquote>If you are talking about Darwin ObjC property (with no feature extension), there is no allowance for default arguments.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>technically have to support with ObjC++ properties but actually haven't gotten around to yet, like what happens when we're doing a compound assignment on an implicit property reference and the getter and setter have really different types. Really I think this is an argument for improving the representation of all property expressions.</div></div></blockquote><div>If you are talking about the same property, they cannot have different types. </div></div><div><br></div><div>- fariborz</div><div><br></div><br></body></html>