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

[Jordan Rose]

> 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. 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, or (in the case of removeLast) because they implement API that's in the same family as the protocol.

Jordan