<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Problem is that methods return wrong type for their family. I will change the diagnostics to say ‘casting’ instead of ‘returning’.<div>John M. may want to add more content to reason for such castings.</div><div><br></div><div>- Fariborz</div><div><br><div><div><div>On Jul 11, 2013, at 11:40 AM, Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Thu, Jul 11, 2013 at 9:48 AM, Fariborz Jahanian <<a href="mailto:fjahanian@apple.com">fjahanian@apple.com</a>> wrote:<br><blockquote type="cite">@interface Fail @end<br>@protocol X @end<br>@implementation Fail<br>-- (id<X>) initWithX<br>+- (id<X>) initWithX // expected-note {{compiler has implicitly changed method 'initWithX' return type}}<br>{<br>- return (id)self; // expected-warning {{casting 'Fail *' to incompatible type 'id<X>'}}<br>+ return (id)self; // expected-warning {{returning 'Fail *' from a function with incompatible result type 'id<X>'}}<br>}<br>@end<br></blockquote><br>FWIW, I don't understand these new diagnostics at all. I understand<br>that with ARC the return type of initWithX must be (Fail*), not<br>(id<X>); but if the compiler has indeed "implicitly changed [the]<br>return type" to (Fail*), then why is it complaining so loudly about<br>the correct "return" statement? [Under ARC, it's always valid to<br>return "self" from an init method.] Or, if the compiler did NOT change<br>initWithX's return type, then why is it saying it did?<br><br><blockquote type="cite">+@implementation UIViewController<br>++ (UIViewController<PMFilterManager> *)newFilterViewControllerForType // expected-note {{compiler has implicitly changed method 'newFilterViewControllerForType' return type}}<br>+{<br>+ UIViewController<PMFilterManager> *filterVC;<br>+ return filterVC; // expected-warning {{incompatible pointer types returning 'UIViewController *' from a function with result type 'UIViewController<PMFilterManager> *'}}<br>+}<br>+@end<br></blockquote><br>These diagnostics just look wrong. UIViewController's<br>newFilterViewControllerForType method is expected by ARC to return<br>(UIViewController*), and in fact that's how it's prototyped (with the<br>addition of an extra protocol, which doesn't hurt anything). And in<br>fact its return statement returns an expression of type<br>(UIViewController<PMFilterManager>*), which is implicitly convertible<br>to (UIViewController*). So these diagnostics are just confusing and<br>useless; there's no error here to diagnose.<br><br>Thoughts?<br>-Arthur</div></blockquote></div><br></div></div></body></html>