[swift-dev] Function overload resolution

[Nevin Brackett-Rozinsky]

func triple(_ x: Int) -> Int {
    return 3 * x
}

extension Int {
    func triple() -> Int {
        return triple(self)     // Error here
    }
}


The error reads:

Playground execution failed:
> error: Test.playground:5:16: error: use of 'triple' refers to instance
> method 'triple()' rather than global function 'triple' in module
> '__lldb_expr_52'
>         return triple(self)     // Error here
>                ^
> Test.playground:5:16: note: use '__lldb_expr_52.' to reference the global
> function in module '__lldb_expr_52'
>         return triple(self)     // Error here
>                ^
>                __lldb_expr_52.



Notice where the error says, “use of 'triple' refers to instance method
'triple()' rather than global function 'triple'”.

Notice further that the instance method takes 0 arguments. In particular,
“self.triple()” is a valid way to call it, and “self.triple(self)” is not.

It is true that the instance method could be called as a type method with 1
argument, “Int.triple(self)”. However, “triple(self)” is not a valid way to
call the type method, which we can demonstrate by removing the global
function entirely:


extension Int {
    func triple() -> Int {
        return triple(self)     // Error here
    }
}


This time the error reads:

Playground execution failed:
> error: Test.playground:3:23: error: argument passed to call that takes no
> arguments
>         return triple(self)
>                      ~^~~~~



So the compiler correctly recognizes that “triple(self)” is not a valid
call to the instance method. Indeed, it has the wrong arity. From there, it
seems to me a small step to reason that, in the case where a function with
the proper signature *does* exist, that it should be called.

 • • •

Also, as a minor point, going back to the original code, notice there are
two diagnostic messages. The second one says, “use '__lldb_expr_52.' to
reference the global function”. However, that does not work, and indeed
every time I run the playground the number shown changes.

So it seems that in a playground, the diagnostic is incorrect, as the
proposed solution does not work. Is there in fact a way to specify the
module for a playground, so as to unambiguously call a global function?

 • • •

In any case, the proper behavior seems clear-cut to my mind. The shorthand
for calling an instance method without “self.” should apply only if there
is a matching instance method to call. When there is no instance method
which could possibly match, but there is a global function that does, then
the unqualified call should resolve to the global function.

Nevin



On Sun, Sep 24, 2017 at 10:16 PM, Robert Widmann <devteam.codafi at gmail.com>
wrote:

> If either function had the correct signature and was being properly
> disambiguated there would not be a diagnostic popped.  Can you provide an
> example of this?
>
> ~Robert Widmann
>
> On Sep 24, 2017, at 8:58 PM, Nevin Brackett-Rozinsky <
> nevin.brackettrozinsky at gmail.com> wrote:
>
> The new diagnostic is fine, the problem is that there should not be an
> error at all. If there is only one function with the proper signature, the
> compiler should not invent a non-existent ambiguity.
>
> The situation I encountered involves functions of different arities, so it
> should be straightforward to select the correct one, yet it still fails to
> compile. I'd like to make it work.
>
> Nevin
>
>
> On Sunday, September 24, 2017, Robert Widmann <devteam.codafi at gmail.com>
> wrote:
>
>> This appears to be resolved (in fact, I remember improving this some time
>> ago).  I get a much better diagnostic now
>>
>> > error: repl.swift:4:16: error: use of 'min' refers to instance method
>> 'min()' rather than global function 'min' in module 'Swift'
>> >         return min(1,2)
>> >                ^
>> >
>> > repl.swift:4:16: note: use 'Swift.' to reference the global function in
>> module 'Swift'
>> >         return min(1,2)
>> >                ^
>> >                Swift.
>>
>> What version of Swift are you still seeing the bad diagnostic in?
>>
>> ~Robert Widmann
>>
>> > On Sep 24, 2017, at 12:03 PM, Nevin Brackett-Rozinsky via swift-dev <
>> swift-dev at swift.org> wrote:
>> >
>> > I recently got bit by SR-2450, and I’d like to try to fix it. However,
>> I’ve never worked on the compiler before and I have some questions:
>> >
>> > 1. Is this a reasonable first bug to tackle?
>> > 2. What resources are available for newcomers to the Swift project?
>> > 3. What will I need to learn about in order to address SR-2450?
>> >
>> > Thanks,
>> >
>> > Nevin
>> > _______________________________________________
>> > swift-dev mailing list
>> > swift-dev at swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170925/4079da42/attachment.html>