<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 7, 2012, at 10:46 AM, Douglas Gregor wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 7, 2012, at 9:43 AM, jahanian <<a href="mailto:fjahanian@apple.com">fjahanian@apple.com</a>> 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; "><br><div><div>On Aug 6, 2012, at 5:42 PM, Jordan Rose wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 6, 2012, at 17:37 , Fariborz Jahanian <<a href="mailto:fjahanian@apple.com">fjahanian@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>On Aug 6, 2012, at 5:09 PM, Jordan Rose wrote:<br><br><blockquote type="cite">Why does this only warn under non-GC?<br></blockquote><br>I don't know. This is an old GCC option and brought it over as-is to clang. I don't have the original gcc radar<br>to look for the rational. Could be that under GC it is safe to do direct assignment while with the advent of<br>properties, users warn to catch such accesses and use the property syntax which controls the ivar<br>access with its own APIs (think atomic vs non-atomic).<br></blockquote></div><br><div>The same is true under ARC, though. If this is a safety warning, it only really needs to be on for MRC and __unsafe_unretained ivars. I think it's more often a consistency thing, though: if you want Key-Value Observing to work right you have to use the properties.</div><div><br></div><div>As a heuristic, people often access ivars directly in -init methods and in -dealloc, since properties may be overridden by subclasses. If we were going to split the difference on the warnings, it could be on by default everywhere <i>except</i> -init and -dealloc methods.</div></div></blockquote><br></div><div>My intention was to closely follow gcc's behavior wrt -Wdirect-ivar-access. </div></div></blockquote><div><br></div><div>There's no point in modeling GCC 4.2's behavior, because it isn't relevant for Objective-C. Wdirect-ivar-access is intended to warn about direct access to ivars in places where one should probably have accessed a property instead. That has nothing to do with GC or ARC, so the warning should not dependent on the (absence of) those features.</div><div><br></div></div></div></blockquote><div><br></div>These points are all covered. We don't care about GC. MRR is covered with this patch. ARC already has tight control on how direct assignment/reference to</div><div>ivars are warned against. We can open up this option for ARC if there are unsafe cases which is not already covered outside this option. But then, ARC's warnings</div><div>are always on by default, this option is not.</div><div><br></div><div>- fariborz</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></div></div></blockquote></div><br></body></html>