[swift-dev] "Near-miss" warnings for protocol conformances

[Douglas Gregor]

> On Nov 2, 2017, at 6:07 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> On Oct 26, 2017, at 9:28 PM, Douglas Gregor via swift-dev <swift-dev at swift.org> wrote:
>> 
>> Unlabeled single-value initializers are probably going to cause a number of false positives, because we can’t figure out which one we meant.
> 
> 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).

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 https://github.com/apple/swift/pull/12808 <https://github.com/apple/swift/pull/12808>.

> 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.

I’m really trying to avoid growing the language with additional annotations.

>> 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.
> 
> 
> 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?

I suspect that these are too specific to Collection

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171107/f9c61123/attachment.html>