Hi Andreas,

There is a known issue associated with overload resolution here. The easiest workaround is to add an extra IComparer<_> argument, which forces the resolution in favour of the generic method (and in any case you may want a particular comparer). A good source of IComparer<_> values is through the values in Microsoft.FSharp.Collections.ComparisonIdentity, e.g.

1
2

let res = System.Array.BinarySearch(arr, 42,ComparisonIdentity.Structural)

or

1
2
3
4
5

let myComparer x1 x2 = Operators.compare (x1 % 17) (x2 % 17)


let res = System.Array.BinarySearch(arr, ,ComparisonIdentity.FromFunction(myComparer))

The problem with overload resolution is a known issue that has not yet been resolved. You can resolve the overload to the "Array" case by upcasting the first parameter to "Array" - indeed this is probably sufficient for you in terms of functionality: you lose some performance and static type checking but for most purposes it will be a sufficient workaround. If you have to call the generic version of the method that doesn't take an IComparer<_> parameter, then the only current way is to use some explicit IL:

1
2
3
4

let binsearch (arr : 'a[]) (x:'a)  = 
    (# "call int32 [mscorlib]System.Array::BinarySearch<!!0>(!!0[],!!0)" arr x : int #)
let arr = Array.init 100 (fun i -> i);;
binsearch arr;;

FWIW the issue with type inference stems from the fact that under F#'s current constraint resolution system the two overloads are equally ambiguous: one involves the instantiation of type variables related to subtyping, the other instantiations related to generics, and F# handles both the same way. We plan on addressing this issue in the next release by two means:

1. allow explicit type parameters to be specified at call sites
2. add a rule for overload resolution that prefers overloads resolved by only taking generic instantiations into account.

Cheers,

Don