Bug - Fixed Function overload resolution

[tricus]

version: kolmafia 17130

I think there is a minor bug in function overloading resolution. A similarly-named function taking a string is matched instead of one taking the exact type (if the former appears before the latter):

string[int] to_array(string _string)
{
  print("Called: string[int] to_array(string _string)");
  string[int] result; result[0] = _string; return result;
}
int[effect] to_array(boolean[effect] effects)
{
  print("Called: int[effect] to_array(boolean[effect] effects)");
  int[effect] result;
  return result;
}
$effects[Got Milk, Ode to Booze].to_array();

// Output:
// Called: string[int] to_array(string _string)
// Returned: aggregate string [int]
// 0 => aggregate boolean [effect]

If you swap the position of the two function definitions it works properly.

Maybe somehow related to the way overload resolution works for string to_string(any)?

I searched and didn't see any other relevant posts about this.

 

[heeheehee]

Hm. Fundamentally the high-level logic is fine -- we first check for an exact parameters match for user-defined functions / built-in functions, then try coercing arguments if valid.

However, I've found a bug in the details of Parser.findFunction, although I'm still investigating. We use operator equality to compare paramType with valueType. This doesn't work with AggregateTypes, which we instantiate as needed, since they don't correspond to the same object.

 

[heeheehee]

One surprisingly small change should fix this -- see r17131. Although, I wonder if I'm being unnecessarily defensive here -- I don't think params should ever contain a null value (this would lead to incorrect behavior if that were well-defined, which I don't think it should be).

 

[fronobulax]

One surprisingly small change should fix this -- see r17131. Although, I wonder if I'm being unnecessarily defensive here -- I don't think params should ever contain a null value (this would lead to incorrect behavior if that were well-defined, which I don't think it should be).

I'm OK with coding defensively. See the Six Rules of Debugging (which I think I first heard of from xKiv) and note the first one is "That Can't Happen".