On Wed, Sep 27, 2017 at 12:23 PM, Jordan Rose <jordan_r...@apple.com> wrote: > > > This is *definitely* a change that would need to go through > swift-evolution. There are a number of potential issues and possibilities > for breaking existing code that’s relying on this shadowing behavior, > intentionally or unintentionally. > > Jordan >
Perhaps I am misunderstanding, but I don’t see how it is possible for code to be relying on this in a manner that would be affected by what’s being discussed. *Things that will change with this bug fix:* If there are both a local function and a global function with the base name being called, and the local function’s signature does not match the call-site but the global function’s does, that is currently a compiler error, but after the bug is fixed the global function will be called. *Things that will stay the same:* 1) If there is only a global function and no local function with the base name being called, and the global function’s signature matches the call-site, currently the global function is called, and it will still be called after the bug is fixed. 2) If there is only a local function and no global function with the base name being called, and the local function’s signature matches the call-site, currently the local function is called, and it will still be called after the bug is fixed. 3) If there is neither a local function nor a global function with the base name being called, currently that is a compiler error, and it will still be one after the bug is fixed. 4) If there are both a local function and a global function with the base name being called, but neither of their signatures match the call-site, currently that is a compiler error, and it will still be one after the bug is fixed. 5) If there are both a local function and a global function with the base name being called, and the local function’s signature matches the call-site, the local function is called currently, and it will still be called after the bug is fixed. • • • The only change here is that something which is a compiler error today, will not be a compiler error once the bug is fixed. There cannot possibly be any valid code which relies on the current behavior, because the current behavior is a compiler error. Am I missing something? Nevin
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev