<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 2, 2017, at 6:07 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Oct 26, 2017, at 9:28 PM, Douglas Gregor via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:<br class=""><br class="">Unlabeled single-value initializers are probably going to cause a number of false positives, because we can’t figure out which one we meant.<br class=""></blockquote><br class="">When we're dealing with unlabeled initializers, can we use tighter rules? For instance, perhaps it should only warn if the near miss has the same parameter types, but different fallibility/throwing/etc., or if the parameter types are closely related (e.g. the concrete parameter type is a subtype of the required parameter type).<br class=""></div></div></blockquote><div><br class=""></div><div>Yeah, I’ll suppress the diagnostic for an initializer with unlabeled parameters. Also for unlabeled subscripts, I think, because they have the same general issue where the base name is fixed by the language. This is implemented in the last commit of <a href="https://github.com/apple/swift/pull/12808" class="">https://github.com/apple/swift/pull/12808</a>.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Alternatively, perhaps we should have an annotation saying that a given default implementation is expected to be used by concrete types and it's not surprising for them to miss. Or we could disable near-miss warnings if a refinement provides a default implementation for a base protocol requirement.<br class=""></div></div></blockquote><div><br class=""></div><div>I’m really trying to avoid growing the language with additional annotations.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">The filter method it’s warning on produces a Set, whereas the requirement expects an Array<Element>. This is a case of intentional overloading, but IMO it’s a reasonable thing to warn about.<br class=""></blockquote><br class=""><br class="">Would it make sense to suppress the warning if the requirement has some fixed return type, but the implementation you're warning about returns (some specialization of) `Self`? Or do you think this is too specific to `Collection` and these kinds of return-type overloads are rare in practice?<br class=""></div></div></blockquote></div><br class=""><div class="">I suspect that these are too specific to Collection</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div></body></html>