> On Apr 25, 2016, at 10:12 AM, Douglas Gregor <dgre...@apple.com> wrote:
>> On Apr 25, 2016, at 10:09 AM, John McCall <rjmcc...@apple.com
>> <mailto:rjmcc...@apple.com>> wrote:
>>
>>> On Apr 25, 2016, at 9:57 AM, Douglas Gregor <dgre...@apple.com
>>> <mailto: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.
>
> By “common words” I mean “words that are common to both names”, not “common
> English words” :)
Oh, I see, of course. Yes, that would probably go a long way towards
minimizing the false positives.
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
