You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But note that simply moving the second f inside g produces the following (afaics) invalid compiler error for both f(123) calls:
func f(_ x: Int) {
print(x)
}
func g() {
func f() {
f(123) // ERROR
}
f(123) // ERROR
}
f(123) // OK
// ERROR = Argument passed to call that takes no arguments
The following program demonstrates that even though the two f-functions have a different number of parameters and different argument labels, the compiler still fails to see that it is the outer f(number: ) that is being called:
(As before, moving the inner f(string: arrayOfStrings: ) out of g() will make it compile successfully.)
And a final one that demonstrates an other invalid error that is produced when the outer f is called before the declaration of the inner f:
func f() {
print("Hi! I'm the only f that is being called in this (valid) program.")
}
func g() {
f() // ERR: Use of local variable `f` before its declaration
func f(compilerBug invalidError: String) {
f() // ERR: Missing argument parameter for parameter `compilerBug` in call
}
f() // ERR: Missing argument parameter for parameter `compilerBug` in call
}
f()
I've reproduced the issue(s) using in Xcode 9.3 beta 2 with both default toolchain and latest development snapshot.
The text was updated successfully, but these errors were encountered:
This is behaving as designed, although people have complained about it before. Overload resolution works on a set of functions in the same context, so in this case once the nested function is found the compiler stops looking for other overloads. You can always use MyModule.f to reference the top-level function.
Oh, ok, thanks! I can understand it after your explanation but I still think it's unintuitive, especially when for example the following compiles fine:
func f() {
print("The f in global scope!")
}
func g() {
func f() {
print("The f nested in g!")
}
f()
}
f() // The f in global scope!
g() // The f nested in g!
Meaning it's OK to shadow functions, but when trying to overload and call the outer f, you get very strange diagnostics (see last example program in the report that is kind of similar to this).
Additional Detail from JIRA
md5: 0aad26add04c38ffcfab162f9cd159dc
Issue Description:
The following program compiles as expected:
But note that simply moving the second f inside g produces the following (afaics) invalid compiler error for both f(123) calls:
The following program demonstrates that even though the two f-functions have a different number of parameters and different argument labels, the compiler still fails to see that it is the outer f(number: ) that is being called:
(As before, moving the inner f(string: arrayOfStrings: ) out of g() will make it compile successfully.)
And a final one that demonstrates an other invalid error that is produced when the outer f is called before the declaration of the inner f:
I've reproduced the issue(s) using in Xcode 9.3 beta 2 with both default toolchain and latest development snapshot.
The text was updated successfully, but these errors were encountered: