Purpose

This PR disables function overloads which only diff in parameters' ranks. That is, the following function overloads are not allowed because parameter xss have the same type int (though with different ranks)

def foo(xs: int[]) {
    ...
}
def foo(xs: int[][]) {
    ...
}

But the following overloads are still valid:

def foo(x: int) {
    ...
}
def foo(x: string) {
    ...
}
def foo(x: int, y: int) {
   ...
}

The main purpose of this change is to reduce the complexity of method resolution for overloaded functions, especially in replication, and to make the program be more predicable from user's point of view. For example, in the following code, it is not so obvious which foo() will be invoked.

def foo(xs: int[], ys: int[][]) {
    ...
}
def foo(xs: int[][], ys: int[]) {
    ...
}
// both foo()s are valid candidates
r1 = foo({{1, 2}, {3, 4}}, {{5, 6}, {7, 8}});    

 // should we replicate on first foo() for the first argument?
r2 = foo({{1, 2}, 3}, {{4, 5}, {6, 7}});        

This PR removes overloads for the following builtins (Note even these builtins have been obsolete. They are replaced by functions in List namespace)

• Equals(var[]..[], var[]..[]), Equals(var, var)
• IndexOf(var[]..[], var[]..[]), IndexOf(var[]..[], var)
• Insert(var[]..[], var[]..[], int), Insert(var[]..[], var, int)
• Print(var[]..[]), Print(var)
• GetType(var[]..[]), GetType(var)

If there are overloads, the rule is the first one wins. There could be other more sophisticated rules, e.g., the function with higher rank parameter wins. One reason of using this simple rule is in delta execution environment, we don't want a newly added function disables its overload and makes the graph stop working.

Declarations

Check these if you believe they are true

• The code base is in a better state after this PR
• Is documented according to the standards
• The level of testing this PR includes is appropriate
• User facing strings, if any, are extracted into *.resx files
• All tests pass using the self-service CI.
• Snapshot of UI changes, if any.
• Changes to the API follow Semantic Versioning, and are documented in the API Changes document.

Reviewers

@aparajit-pratap

FYIs

@kronz @Racel