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-2810] Inconsistent function overload resolution for functions with variadic parameters #45414

Open
swift-ci opened this issue Sep 30, 2016 · 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

@swift-ci
Copy link
Collaborator

Previous ID SR-2810
Radar None
Original Reporter tonisuter (JIRA User)
Type Bug
Environment

macOS 10.12, Swift 3.0

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

md5: e88b20b087340e2ceef93c5ec3c2f5bc

Issue Description:

In the following code example, there are two functions with the same base name f and the same variadic parameter x. Both functions are candidates for all four function calls shown below. However, even though the function calls only differ in the number of arguments that are passed to the variadic parameter x, function overload resolution doesn't always pick the same function:

func f(x: Int..., y: Int = 0) { print(x, y) }
func f(x: Int...) { print(x) }

f()              // []
f(x: 1)              // [1]
f(x: 1, 2)       // [1, 2] 0
f(x: 1, 2, 3)        // [1, 2, 3]

As far as I can tell, the first function is selected when the number of arguments passed to the variadic parameter x matches the total number of parameters of the first function. Here's another example:

func f(x: Int..., y: Int = 0, z: Int = 0) { print(x, y, z) }
func f(x: Int...) { print(x) }

f()              // []
f(x: 1)              // [1]
f(x: 1, 2)       // [1, 2]
f(x: 1, 2, 3)        // [1, 2, 3] 0 0
@belkadan
Copy link
Contributor

That's pretty bad. You should need the external parameter name to refer to y and z, but even if the declarations included the _ the compiler should be consistent.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jan 3, 2018

Comment by Kilian Koeltzsch (JIRA)

Just tried out something rather similar.

func foo(_ bar: Int...) {
    bar.forEach {
        print($0)
    }
}

func foo(_ bar: Int, _ baz: Int) {
    print(bar)
    print(baz)
}

foo(1, 2)

I would expect to get a compiler warning for this being ambiguous. Instead implicitly the second

@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

2 participants