Suggestion for incorrect label used might be improved

[valeriyvan]

let int = 7
let uint = UInt(bitpattern: int) // Error: Extraneous argument label 'bitpattern:' in call
                                 // Suggested fix: Remove 'bitpattern: '

Among suggested fixes should be Use 'bitPattern: ' label instead of 'bitpattern: '.

[Rajveer100]

So if I am not wrong, this fix is should be done for all such cases where such error message for incorrect label occurs? Right?

[Rajveer100]

@valeriyvan

[AnthonyLatsis]

This is an overload resolution issue. A more self-contained reproducer:

struct Foo {
  func bar(_: Int) {}
  func bar(sesame: Int) {}
}

func test(foo: Foo) {
  foo.bar(sesam: 0)
}

Overload resolution should favor a labeled function over a non-labeled one with a matching type signature so long as the labels are provided and the typo correction limit is not exceeded for each label.

[Rajveer100]

Ahh, I see, so I think there must a preference order Swift must have specified by default which needs to be changed while it debugs and finds the matching constructors.

[Rajveer100]

Just to be sure, this particular issue is to be dealt with function overloading (i.e. Overload Resolution), where functions with closer matching parameters must be given greater preference, and once found, we can add the fixit, if I correctly interpreted it, right?

[Rajveer100]

struct Foo {
  func bar(_: Int) {}
  func bar(sesame: Int) {}
  func bar(parameter1: Double, parameter: Bool) {}
}

func test(foo: Foo) {
  foo.bar(parameter: 0.0)
}

I also added another overloaded function to check how worse can the diagnostics get, so here are the error results:

error: missing argument for parameter 'parameter1' in call
  foo.bar(parameter: 0.0)
          ^
          parameter1: <#Double#>, 
note: 'bar(parameter1:parameter:)' declared here
  func bar(parameter1: Double, parameter: Bool) {}
       ^
error: cannot convert value of type 'Double' to expected argument type 'Bool'
  foo.bar(parameter: 0.0)
                     ^

[AnthonyLatsis]

Just to be sure, this particular issue is to be dealt with function overloading (i.e. Overload Resolution), where functions with closer matching parameters must be given greater preference, and once found, we can add the fixit, if I correctly interpreted it, right?

That’s the basic idea. In this case, if the user did provide an argument label and we end up with an ambiguity purely because the argument label does not match, we should first see if resorting to a certain amount of typo correction fixes the ambiguity.