> On Apr 25, 2016, at 9:57 AM, Douglas Gregor <dgre...@apple.com> wrote:
>> On Apr 22, 2016, at 6:08 PM, John McCall <rjmcc...@apple.com 
>> <mailto:rjmcc...@apple.com>> wrote:
>> 
>>> On Apr 22, 2016, at 3:33 PM, Douglas Gregor via swift-dev 
>>> <swift-dev@swift.org <mailto:swift-dev@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.

> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

Reply via email to