> On Apr 25, 2016, at 10:09 AM, John McCall via swift-dev <swift-dev@swift.org> > 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.
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@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
