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-6896] Regression: HOF overloads differing in @autoclosure are ambiguous called with forwarded @autoclosure parameter (Swift >= 4.1) #49445

Closed
swift-ci opened this issue Feb 1, 2018 · 5 comments
Assignees
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself regression swift 4.1 type checker Area → compiler: Semantic analysis

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Feb 1, 2018

Previous ID SR-6896
Radar rdar://problem/37160679
Original Reporter dal (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

macOS 10.13.2 (17C88)

Xcode 9.3 beta (9Q98q)

Apple Swift version 4.1 (swiftlang-902.0.34 clang-902.0.30)

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug, 4.1Regression, TypeChecker
Assignee @xedin
Priority Medium

md5: 345f8d1ebfc5445534b7f1b936372631

Issue Description:

Two overloads of a higher order function differing only in `@autoclosure` are not considered conflicting declarations.

When such an overloaded HOF is called with a closure value, or with a literal (creating an auto-closure), there is no ambiguity.

However, when the overloaded HOF is called by forwarding a closure from a named parameter which is also `@autoclosure`, there is an unexpected ambiguity.

NOTE: This issue does not occur in Swift <4.1 (from the last Xcode 9.2 build). It appears a regression has been introduced since 4.0.3.

public enum Result: Equatable {
    case autoclosured(Int)
    case plain(Int)
    
    public static func ==(lhs: Result, rhs: Result) -> Bool {
        switch (lhs, rhs) {
        case (.autoclosured(let x), .autoclosured(let y)):
            return x == y
        case (.plain(let x), .plain(let y)):
            return x == y
        default:
            return false
        }
    }
}

public func foo(_ f: @autoclosure () -> Int) -> Result {
    return .autoclosured(f())
}

public func foo(_ f: () -> Int) -> Result {
    return .plain(f())
}

// OK
assert(foo(1) == Result.autoclosured(1))

// OK
let f: () -> Int = { return 2 }
assert(foo(f) == Result.plain(2))

func bar1(f: () -> Int) {
    // OK
    foo(f) // bar1
}

func bar2(f: @autoclosure () -> Int) {
    // Ambiguity error.
    foo(f) // bar2
}
@belkadan
Copy link
Contributor

belkadan commented Feb 2, 2018

@rudkx, you were just looking at this, right?

@rudkx
Copy link
Member

rudkx commented Feb 2, 2018

I replied to a question on the forums that was related, but haven't actually seen a bug to look at before this.

@rudkx
Copy link
Member

rudkx commented Feb 2, 2018

@swift-ci create

@swift-ci
Copy link
Collaborator Author

swift-ci commented Feb 2, 2018

Comment by Dylan A. Lukes (JIRA)

As an example of a real world project affected by this regression, see `typelift/SwiftCheck`. I expect there are plenty of other ones.

@xedin
Copy link
Member

xedin commented Feb 8, 2018

PR #14441 has been merged to master. dal (JIRA User) please use next nightly snapshot to validate and thanks for reporting!

@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 regression swift 4.1 type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

5 participants