[swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

[Douglas Gregor]

> On Apr 25, 2016, at 3:30 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> I, personally, *really* don’t want yet another decorator keyword to indicate the intent here, because I believe the user has already indicated intent by stating conformance to the protocol P.
> 
> I don't find this so compelling in a language with defaulted requirements.

If we didn’t have defaulted/optional requirements, this wouldn’t be an issue at all.

> The place where we're seeing this problem the most is optional requirements in ObjC protocols (because of all the name changes), but it's really the same thing: it's hard to know if a particular member is intended to be part of a protocol or just something that happens to be similar.



> 
>> It’s somewhat frustrating that these are *all* false positives. However, they seem like “reasonable” false positives, in the sense that they’re close enough to the requirement to be justifiable, and the suggested recovery strategies look acceptable.
> 
> I agree that these are all reasonable, but I don't think moving decls to extensions is a great answer. A lot of these close names might be close because they're helper functions,

You can explicitly give them less visibility than the conformance, which makes it clear that they’re helper functions and disables the diagnostic.

> or (in the case of removeLast) because they implement API that's in the same family as the protocol.


It seems less onerous to move removeLast out to a different extension than it is to splat some “implements” keyword on a bunch of declarations within an extension whose purpose is to conform to a protocol P:

	extension X : P {
	  // this is how X conforms to P
	}



	- Doug