This is confusing.

If we have

M1(params int[] arr) . . . 

and

M1(in int[] arr) ...

And I call with M1( new int[] {1,2}) - i.e. first is applicable in normal (not expanded) form
I would expect the byval method to be selected, regardless if it was declared params or not. The comment seems to say the opposite.

We need some tests for this scenario - with params overload matching in normal or expanded form. (in expanded form I expect it to not be selected) #Resolved

@VSadov We already have a test that tests params expansion with in: PassingInArgumentsOverloadedOnInParams.
For the array variation, we are still reporting ambiguity (I prefer this over selecting the by-val one, as it can break the caller). Will add another test for that variation and explain in the comment. #Closed

ParameterSymbol parameter2 [](start = 109, length = 26)

Consider using discard. #Closed

p1.IsParams [](start = 17, length = 11)

See IsValidParams helper how to check for valid params parameter. Also, why should this matter if candidate is not using expanded form? #Closed

// If an ambiguity exists between 'by-val' and 'in' parameter, choose the 'by-val' one, except if it was params, [](start = 12, length = 112)

It feels suspicious that we do this check before we checked which candidate uses BetterConversionFromExpression. Even if we do that immediately after, we might still introduce a breaking change as the tie breaking rules that are executed today after this function can resolve the ambiguity differently. #Closed

It seems the order of paremeters matters.
I.E. we can resolve M(1, 1) when
M(in int x, int y)
M(int x, in int y)

Second wins. Is that intentional? #Resolved

"Unequal parameters counts are handled in an earlier stage" [](start = 65, length = 59)

Could you please point to the place that does that? #Closed

Check lines 1441-1519. They should handle these cases where we end up with mismatching parameter count because of unused optional or expanded ones. I'll add a test as well.

In reply to: 151523306 [](ancestors = 151523306)

I see that code comparing the number of parameters used, but not the number of parameters declared.

In reply to: 151544214 [](ancestors = 151544214,151523306)

for (i = 0; i < m1Original.Length; i++) [](start = 12, length = 39)

I think we should only look at parameters that have arguments. #Closed

var p2 = m2Original[i]; [](start = 16, length = 23)

It looks like these parameters may correspond to different arguments. Why would we look at them in this case? #Closed

return BetterResult.Left; [](start = 20, length = 25)

Returning too early? Please add tests for multiple arguments including cases when different arguments point to a different winners. #Closed

Method != null && [](start = 20, length = 17)

Same comment as for Unary operator. #Closed

Method != null && [](start = 20, length = 17)

Same comment. Consider passing ref-kinds to the constructor explicitly, the same way as we do with types. #Closed

As an alternative, we could always return None when Method is null.

In reply to: 155020652 [](ancestors = 155020652)

Will take into account null methods (built-in language operators that have no method symbol).

In reply to: 155021847 [](ancestors = 155021847,155020652)

if (op1.LeftRefKind == RefKind.None && op2.LeftRefKind == RefKind.In) [](start = 12, length = 69)

It feels like the logic here could be simplified if we add a helper that calculates the best among two ref kinds. Then we call it for both sides and then reason about final answer.
Something like this:

BetterResult fromLeft = better(op1.LeftRefKind, op2.LeftRefKind);
BetterResult fromRight = better(op1.RightRefKind, op2.RightRefKind);
if (fromLeft == BetterResult.Neither || fromLeft == fromRight)
    return fromRight;
if (fromRight == BetterResult.Neither)
    return fromLeft;
return BetterResult.Neither;
``` #Resolved

To me, the existing implementation is easier to read/trace. However, I don't feel strongly about this. I can implement your suggestions if you think it is the better alternative.

In reply to: 155026276 [](ancestors = 155026276)

Method [](start = 20, length = 6)

Please add cast to object. #Resolved

Method [](start = 20, length = 6)

Please add cast to object. #Resolved

Method [](start = 20, length = 6)

Please add cast to object. #Resolved

.Single() [](start = 55, length = 9)

Is Single() better than just [0]? #Resolved

It will throw a more descriptive exception if something went wrong.

In reply to: 155394341 [](ancestors = 155394341)