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-10573] Unexpected behavior of variadic parameters #52973

Open
swift-ci opened this issue Apr 29, 2019 · 5 comments
Open

[SR-10573] Unexpected behavior of variadic parameters #52973

swift-ci opened this issue Apr 29, 2019 · 5 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

Previous ID SR-10573
Radar None
Original Reporter linqingmo (JIRA User)
Type Bug
Environment

Xcode 10.2.1

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

md5: 71e965ac97186a32717d5be022d32ced

Issue Description:

https://forums.swift.org/t/unexpected-behavior-of-variadic-parameters/23892

class Test {
    func test() {
        print("test")
    }
    
    func test(_ values: Int...) {
        print(values)
    }
}

let t = Test()
t.test() // prints test

However if func test() is implemented in extension of Protocol, it behaves different.

protocol P {
    func test()
}

extension P {
    func test() {
        print("test")
    }
}

class Test: P {
//    func test() {
//        print("test")
//    }
    
    func test(_ values: Int...) {
        print(values)
    }
}

let t = Test()
t.test() // prints []
@belkadan
Copy link
Contributor

This seems like correct behavior to me: in both cases the compiler has to choose which test is more specific. In the first case, the only thing it has to go on is whether it's going to need to use variadics, and the preference there is to not use variadics. In the second, though, there's also the difference in where the method is implemented: a class is more specific than a protocol it conforms to. That's considered a more important difference.

@belkadan
Copy link
Contributor

cc @xedin, this is kind of the opposite of the Apple-internal Radar about UIView and UICoordinateSpace.

@swift-ci
Copy link
Collaborator Author

Comment by LinQingmo (JIRA)

@belkadan , it is true the compiler has to choose which is more specific. Can we call a variadic func with zero arguments?

class Test {
  func test(values: Int...) {
     print(values)
  }

  func test(values: [Int]) {
     print(values)
  }
}

let t = Test()
t.test(values: 1, 2, 3) // prints [1, 2, 3]
t.test() // prints [], why no label?
t.test(values: []) // prints [], with label

@belkadan
Copy link
Contributor

That is a little weird, but certainly we do want to allow calling an unlabeled variadic function with zero arguments.

@swift-ci
Copy link
Collaborator Author

Comment by LinQingmo (JIRA)

If calling an unlabeled variadic func with zero arguments is allowed, then calling a labeled variadic func with zero arguments should also be allowed?

class Test {
    func test(values: Int...) {
        print(values)
    }
}

let t = Test()
t.test(values:) // ??? func with label and without label should be different func?

Also

class Test {
    func test(_ values: Int...) {
        print(values)
    }
    func test(values: Int...) {
        print(values)
    }
}

let t = Test()
t.test(1, 2, 3) // valid
t.test(values: 1, 2, 3) // valid

t.test() // call which one? Ambiguous use of 'test'.

@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
Projects
None yet
Development

No branches or pull requests

2 participants