[swift-dev] Function overload resolution

[Nevin Brackett-Rozinsky]

On Wed, Sep 27, 2017 at 12:23 PM, Jordan Rose <jordan_rose at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170927/87fd6653/attachment.html>