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

[Kate Stone]

> On Apr 25, 2016, at 10:09 AM, John McCall via swift-dev <swift-dev at swift.org> wrote:
> 
>> On Apr 25, 2016, at 9:57 AM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>>> On Apr 22, 2016, at 6:08 PM, John McCall <rjmccall at apple.com <mailto: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.
> 
> Any shift in the heuristic will eliminate false positives at the risk of creating false negatives.
> 
> A word-by-word heuristic allows you to catch a large number of typos in a long method name without matching completely different words just because the method name is long.  That seems like the right trade-off to me.

Common mistakes may well include omitting a word or inserting an extra word.  The resulting cascade of word-by-word mismatches is something I’d expect our algorithm to deal with more gracefully than purely word index-based comparisons could handle.

>> 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.
> 
> I think you have fallen a bit too in love with dictionaries.
> 
>> 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.
> 
> This does not feel like it leads to a reasonable general principle.  At best it calls for some way to opt in to a warning about implementing only "related" methods, analogous the related-type warnings in ObjC ARC bridging.
> 
> John.
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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