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-10917] Cannot disambigue if generic function throws #53308

Open
krzyzanowskim opened this issue Jun 11, 2019 · 2 comments
Open

[SR-10917] Cannot disambigue if generic function throws #53308

krzyzanowskim opened this issue Jun 11, 2019 · 2 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself type checker Area → compiler: Semantic analysis

Comments

@krzyzanowskim
Copy link
Contributor

Previous ID SR-10917
Radar None
Original Reporter @krzyzanowskim
Type Bug
Environment

Apple Swift version 5.1-dev (LLVM e56fafcd29, Swift c2848e7)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, TypeChecker
Assignee None
Priority Medium

md5: bf2c37d4d3b2f1809e556cee6898b163

Issue Description:

here's the thing, foo<>() and bar<>() from below snippet looks similar, except there's one difference where foo<_>() throws and rethrows closure parameter. This makes Swift unable to resolve expected Optional T

https://gist.github.com/krzyzanowskim/2746f2fa4b816b19f38196d27b741994

        class A {}
    
    // foo
    
    func foo<T>(_ v: T, handler: () -> Void) -> T {
        print("regular")
        return v
    }
    
    func foo<T>(_ v: T?, handler: () throws -> Void) rethrows -> T? {
        print("optional")
        return v
    }
    
    // bar
    
    func bar<T>(_ v: T, handler: () -> Void) -> T {
        print("regular")
        return v
    }
    
    func bar<T>(_ v: T?, handler: () -> Void) -> T? {
        print("optional")
        return v
    }
    
    let result1: A? = foo(A(), handler: {}) // error: ambiguous use of 'foo(_:handler:)'
    let result2: A? = bar(A(), handler: {}) // ok, "optional"

I can't really tell, maybe it's expected behavior. I'm having a hard time to understand it, so I appreciate if you can explain it to me a bit.

@belkadan
Copy link
Contributor

Yeah, I don't think Swift uses throwing-ness to rank overloads. @xedin?

@xedin
Copy link
Member

xedin commented Jun 13, 2019

@krzyzanowskim The problem here is that when we rank overloads we take into account all of the parameters and we can't actually convert `() -> Void` into `() -> throws Void` which makes two overloads of `foo` unrelated for ranking purposes. At the same time in case of `bar` functions are convertible, so ranking can pick overload based on the expected optionality of value.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
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 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants