Coming from Java & C#, I find having to cast up to the interface type in this situation to be a bit strange and verbose. May be I'll get used to it. Is it possible to eliminate the need to do the upcast? Or is this truly a better design?

1
2
3
4
5
6
7
8
9

type IMathService =
  abstract Multiply : int * int -> int
  
type MathService() =
  interface IMathService with
    member x.Multiply(a:int, b:int) = a * b
    
let math = new MathService() :> IMathService
let result = math.Multiply(5,4)

See F# Manual, 8.5 Interface Specifications and Implementations
"Interface members are called by first casting to the interface type:"
[link:research.microsoft.com]

C# has explicit interfaces too:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

    public interface IFoo
    {
        void Method();
    }
    public class Foo : IFoo
    {
        void IFoo.Method()
        {
        }
        public static void Example()
        {
            Foo foo = new Foo();
            foo.Method();  // does not compile
            (foo as IFoo).Method(); // does
        }
    }

The differences are that in F#, interfaces are implemented explicitly by default, whereas in C# they are not, and that in F# there is no syntax to have one method implement both.

The value of explicit interfaces is that they can help reduce complexity and make code more explicit. With many interfaces, you would never call the method on a concrete object, you would only call it on an object that was already upcast to the type. That is, often you'll have a class implement an interface, not so that a user will new up the class and call the method, but instead because a user will new up the class and hand it to some framework that knows how to process IFoos or whatever. In that case, the framework will just keep a collection of IFoo objects and call those methods. When a user does "myFoo." and the intellisense comes up, if IFoo is implemented explicitly, the IFoo methods don't appear, reducing the user-facing complexity for common user scenarios. (Try newing up some WPF objects and look at the hundreds and hundreds of methods that appear in intellisense. How many of those are you likely to call? How many of those are only there to support interaction with other parts of WPF framework? Wouldn't it be nice if more of those interfaces you don't care about were out of your face?)

On the other hand, there are also cases where the interface methods are also intentionally user-facing. List : IList is a good example. Users who have just newed up a List will call Add(), Clear(), etc. But also general methods that work on arbitrary-concrete-collection ILists will also call these methods. In this case, you don't want the interface to be explicit, you want both the users of the concrete type and users targeting the interface to see the same method.

C# prefers the latter strategy, but has a little-known and little-used syntax support for the former. F# prefers the former strategy, and has no syntax sugar for the latter (which is why you have to 'repeat yourself').

I don't know what 'the right/best answer is', but I hope this illuminates the issues that play into the pros and cons of have interface methods automatically show up on concrete class types.