[SR-8896] Strange priorities of overloaded functions #51402

swift-ci · 2018-10-02T11:11:20Z


Previous ID	SR-8896
Radar	None
Original Reporter	koher (JIRA User)
Type	Bug

Environment

Xcode Version 10.0 (10A255)

Additional Detail from JIRA


Votes	1
Component/s	Compiler
Labels	Bug, LanguageFeatureRequest, TypeChecker
Assignee	None
Priority	Medium

md5: f29a7e269390faed1efed185be434365

Issue Description:

I think the result of the following code is strange.

class Animal {}
class Cat<T>: Animal {}

func foo(_: Animal) { print("Animal") }
func foo<T>(_: Cat<T>) { print("Cat") }

foo(Cat<Int>()) // Animal

It seems that non-generic functions are always prior to generic functions between overloads.

It is a more realistic case that `PartialKeyPath` is selected prior to `KeyPath` in the situation like below.

struct Foo {
    var x: Int = 42
    func bar(keyPath: PartialKeyPath<Foo>) { print("PartialKeyPath") }
    func bar<T>(keyPath: KeyPath<Foo, T>) { print("KeyPath") }
}

let path: KeyPath<Foo, Int> = \.x
Foo().bar(keyPath: path) // PartialKeyPath

In addition, if both of `foo` functions in the first example are generic, `Cat`'s one is selected.

func foo<X>(_: X, _: Animal) { print("Animal") }
func foo<X, T>(_: X, _: Cat<T>) { print("Cat") }

foo((), Cat<Int>()) // Cat

I think such behavior is confusing. Some languages, e.g. Kotlin, shows "Cat" for the code like the first example. Is this behavior in Swift intentional?

belkadan · 2018-10-02T17:43:21Z

I think it's deliberate that non-generic functions are considered before generic ones, yes, but I can see how that's not desirable here. @rudkx, @xedin?

xedin · 2018-10-02T18:02:01Z

Yes, unfortunately this is a performance hack we have at the moment, if overload with concrete types matches, solver doesn’t consider generic ones... @rudkx is working on improving this situation.

swift-ci · 2018-10-03T05:28:08Z

Comment by Yuta Koshizawa (JIRA)

That sounds great 🙂

NevinBR · 2020-01-26T01:33:32Z

I just ran into this today in Swift 5.1.3 with Xcode 11.3.1, when implementing a type-erasing wrapper. The result was an infinite hang because the call from the superclass into the generic subclass implementation was treated as recursive into itself instead:

class A {
  func foo(_ a: A) { fatalError() }
  func foo<U>(_ b: B<U>) { fatalError() }
}

final class B<T>: A {
  override func foo(_ a: A) { a.foo(self) }  // should call foo<U> but actually calls itself
  override func foo<U>(_ b: B<U>) { print("done") }
}

let b = B<Int>()
b.foo(b)    // endless loop

The workaround is to rename one of the functions, but that really shouldn’t be necessary because B is clearly more specific than A here.

swift-ci transferred this issue from apple/swift-issues Apr 25, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SR-8896] Strange priorities of overloaded functions #51402

[SR-8896] Strange priorities of overloaded functions #51402

swift-ci commented Oct 2, 2018

belkadan commented Oct 2, 2018

xedin commented Oct 2, 2018

swift-ci commented Oct 3, 2018

NevinBR commented Jan 26, 2020

[SR-8896] Strange priorities of overloaded functions #51402

[SR-8896] Strange priorities of overloaded functions #51402

Comments

swift-ci commented Oct 2, 2018

belkadan commented Oct 2, 2018

xedin commented Oct 2, 2018

swift-ci commented Oct 3, 2018

NevinBR commented Jan 26, 2020