> On Apr 25, 2016, at 10:09 AM, John McCall <[email protected]> wrote:
>
>> On Apr 25, 2016, at 9:57 AM, Douglas Gregor <[email protected]
>> <mailto:[email protected]>> wrote:
>>> On Apr 22, 2016, at 6:08 PM, John McCall <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>> On Apr 22, 2016, at 3:33 PM, Douglas Gregor via swift-dev
>>>> <[email protected] <mailto:[email protected]>> 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” :)
- Doug
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
