Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-1416] constraints overloaded generic functions fail to specify inside another generic function #44025

Closed
swift-ci opened this issue May 5, 2016 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented May 5, 2016

Previous ID SR-1416
Radar None
Original Reporter lingol (JIRA User)
Type Bug
Status Resolved
Resolution Invalid
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: f332a23936885f2cb54f1255fcfe38cf

Issue Description:

Consider this as a bug:

func foo<T>(obj : T) {
    print("calling generic function")
}

func foo<T : AnyObject>(obj : T) {
    print("calling specific function")
}

func test<T>(obj : T) {
    foo(obj)
}

class AClass {
}

let obj = AClass()
// calling specific function
foo(obj)
// calling generic function
test(obj)
@belkadan
Copy link
Contributor

belkadan commented May 5, 2016

This is correct behavior. Overload resolution is done at compile-time, not run-time.

@swift-ci
Copy link
Collaborator Author

swift-ci commented May 6, 2016

Comment by Ling Guo (JIRA)

I can't agree. C++'s generic is done at compile-time, yet it can specify correctly. Why swift can't?

C++:

class AClass {
};

template <typename T>
void foo(T obj) {
    NSLog(@"calling generic function");
}

template <>
void foo(AClass obj) {
    NSLog(@"calling specific function");
}

template <typename T>
void test(T obj) {
    foo(obj);
}

auto obj = AClass();
// calling specific function
foo(obj);
// calling specific function
test(obj);

@swift-ci
Copy link
Collaborator Author

swift-ci commented May 6, 2016

Comment by Ling Guo (JIRA)

Also, calling foo inside another generic function, which loses no type-information, is clearly can be resolve at compile-time.

From my point of view, calling foo directly makes no difference with calling it inside a generic function, for both have full type-information, at compile-time.

@belkadan
Copy link
Contributor

belkadan commented May 6, 2016

Let me put it a different way: Swift's generics use run-time dispatch (because you're going through a protocol or base class), but overload resolution uses compile-time dispatch.

In C++, both of those are compile-time decisions, because templates use an instantiation model, where you get a different copy of the code for every argument you call it with. Swift, by contrast, passes a "witness table" at run time, which describes how to perform any of the operations in the protocol. Since there's only one copy of the code, it can only call one foo method.

If you want foo to be dynamically dispatched, put it in the protocol.

@swift-ci
Copy link
Collaborator Author

Comment by Ling Guo (JIRA)

So only one copy of generic function exists, that explains a lot. Thanks for the inside point of view.

@swift-ci
Copy link
Collaborator Author

Comment by Ling Guo (JIRA)

So I tried it by protocol. I got unexpected result. Did I miss something here?

indirect enum AEnum : CustomDebugStringConvertible {
    case BasicType(String)
    case ContainerType(AEnum)
    
    var debugDescription: String {
        switch self {
        case let .BasicType(str):
            return str
        case let .ContainerType(recusion):
            return "[\(recusion)]"
        }
    }
}

protocol Aprotocol {
    static func getEnum() -> AEnum
}
extension Aprotocol {
    static func getEnum() -> AEnum {
        return AEnum.BasicType("\(self.self)")
    }
}

extension Int : Aprotocol {
}

extension Array : Aprotocol {
}

extension Array where Element : Aprotocol {
    static func getEnum() -> AEnum {
        return AEnum.ContainerType(Element.getEnum())
    }
}

func testTypeRecusion() {
    print(Int.getEnum())    // Int
    print([Int].getEnum())  // [Int]
    print([[Int]].getEnum())  // [Array<Int>], expected [[Int]]
}

@belkadan
Copy link
Contributor

It's the same issue. Array has two methods called getEnum, but only one of them can satisfy the requirement in Aprotocol, and it has to be the more general one. If you want to dynamically dispatch based on types other than the type of self, you have to actually write that in the function body:

extension Array : Aprotocol {
  static func getEnum() -> AEnum {
    if let ContainerElem = Element.self as? Aprotocol.Type {
      return AEnum.ContainerType(ContainerElem.getEnum())
    }
    return AEnum.BasicType("\(self)")
  }
}

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

2 participants