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

Douglas Gregor dgregor at apple.com
Mon Apr 25 11:57:08 CDT 2016


> On Apr 22, 2016, at 6:08 PM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Apr 22, 2016, at 3:33 PM, Douglas Gregor via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> Hi all,
>> 
>> A common complaint with protocol conformance checking is that it’s easy to make a little mistake when trying to implement a protocol requirement that has a default implementation. Here is a silly example:
>> [snip]
>> 
>> Naturally, this handles typos as well, e.g.,
>> 
>> t2.swift:12:8: warning: instance method 'foob(value:)' nearly matches optional requirement 'foo(value:)' of protocol 'P'
>>   func foob(value: Float) { }
>>        ^
>> t2.swift:12:8: note: rename to 'foo(value:)' to satisfy this requirement
>>   func foob(value: Float) { }
>>        ^~~~
>>        foo
>> 
>> Running this on the standard library produces a number of results:
>> 
>> /Users/dgregor/Projects/swift/swift/stdlib/public/core/Arrays.swift.gyb:726:24: warning: instance method 'removeLast()' nearly matches optional requirement 'removeFirst()' of protocol 'RangeReplaceableCollection'
>>   public mutating func removeLast() -> Element {
>>                        ^
>> /Users/dgregor/Projects/swift/swift/stdlib/public/core/Arrays.swift.gyb:726:24: note: rename to 'removeFirst()' to satisfy this requirement
>>   public mutating func removeLast() -> Element {
>>                        ^~~~~~~~~~
>>                        removeFirst
>> /Users/dgregor/Projects/swift/swift/stdlib/public/core/Arrays.swift.gyb:726:24: note: move 'removeLast()' to another extension to silence this warning
>>   public mutating func removeLast() -> Element {
>>                        ^
>> /Users/dgregor/Projects/swift/swift/stdlib/public/core/RangeReplaceableCollection.swift:158:17: note: requirement 'removeFirst()' declared here
>>   mutating func removeFirst() -> Iterator.Element
>>                 ^
> 
> Would a word-by-word edit-distance heuristic work better?  That is, removeFirst is not a plausible typo for removeLast because First is not a plausible typo for Last.

A word-by-word edit distance seems to imply that if *any* word is too far off, reject. I’m a bit concerned that it would create false negatives.

One possibility in this space would be to remove common words from consideration. That way, only the mismatching words will be used to do the edit-distance computation, so the one-mistake-per-N-characters-typed heuristic wouldn’t consider the completely-matching parts.

In defense of the warning in this case: RangeReplaceableCollection has a “removeFirst” but not a “removeLast”; the conforming type here is implementing “removeLast” but not “removeFirst”. It is *so easy* to imagine this as programmer error that the warning feels justified.

	- Doug


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


More information about the swift-dev mailing list