具有类型和接口继承的F＃奇怪行为

Question

Here is a piece of code that works after a couple of trials and errors, but I do not understand why it works in this particular way? Is it by design and the rules are written in stone in some specs, or it works by incident in this case? Comments in the code explain it all, but the question specifically is:

Why the type B_from_A doesn't see that the slot for IA.Item is already implemented by the parent A , but then it allows only partial implementation of IA , so it actually sees that SharedMethod is already implemented in the parent.

open System
open System.Collections.Generic

type IA = // only read methods
    abstract Item : int -> int with get
    abstract SharedMethod : int -> int

type IB = // allows in-place changes
    inherit IA
    abstract Item : int -> int with get, set

type IC = // immutable, returns new version with changes
    inherit IA
    abstract Set: int -> int -> IC

type A() =
    let dic = Dictionary<int,int>() // some complex internal data structure
    member internal this.Dic = dic
    member this.SharedMethod(i) = pown dic.[i] 2
    interface IA with
        member this.Item with get(i) = dic.[i]
        member this.SharedMethod(i) = this.SharedMethod(i) // custom operation on item

type B_from_A() =
    inherit A()
    // without this partial implementation I get an error:
    // Script1.fsx(111,18): error FS0361: The override 'get_Item : int -> int' 
    // implements more than one abstract slot, e.g. 'abstract member IB.Item : int -> int with get' 
    // and 'abstract member IA.Item : int -> int with get'
    interface IA with // partial interface implementation
        member this.Item with get(i) = this.Dic.[i] // required to remove error FS0361
        // !!! but there is no this.SharedMethod(i) here, so the type knows that this slot is 
        // implemented by parent A. Why it asks me to explicitly add Item get here?

    interface IB with
        member this.Item 
            with get(i) = this.Dic.[i] // implements more than one abstract slot without IA above
            and set i v = this.Dic.[i] <- v



type B() = // independent implementation
    let dic = Dictionary<int,int>()
    interface IA with
        member this.Item with get(i) = dic.[i]
        member this.SharedMethod(i) = pown dic.[i] 2
    interface IB with
        member this.Item  
            with get(i) = dic.[i]  
            and set i v = dic.[i] <- v
// If go from B to A, type A_from_B() won't be able to hide mutation methods in IB?
// It is more natural to add functionality than to hide or block it like some SCG ReadOnly collections do (e.g. throw on Add with InvalidOp)
// Therefore keep data structure inside A but add methods to change it inside B_from_A

Also where could I read fast and short about abstract slots and all the low level machinery inside F# polymorphism implementation?

Answer 1

This behaviour is completely defined by the spec

Firstly from 8.14.3 Interface Implementations:

Each member of an interface implementation is checked as follows:

· The member must be an instance member definition.

· Dispatch Slot Inference (§14.7) is applied.

· The member is checked under the assumption that the “this” variable has the enclosing type.

And then the quoted section:

14.7 Dispatch Slot Inference The F# compiler applies Dispatch Slot Inference to object expressions and type definitions before it processes their members. For both object expressions and type definitions, the following are input to Dispatch Slot Inference:

· A type ty0 that is being implemented.

· A set of members override xM(arg1...argN).

· A set of additional interface types ty1 ... tyn.

· A further set of members override xM(arg1...argN) for each tyi.

Dispatch slot inference associates each member with a unique abstract member or interface member that the collected types tyi define or inherit.

As a result, each function can only work once - you can't get the double implementation that you want.

Answer 2

The behavior you describe occurs because IB inherits IA , both of them defining an Item property accessor. Therefore, the B_From_A.IB.Item property accessor implementation has two slots available. However, when you add the B_From_A.IA.Item implementation, one slot is already occupied, so that no ambiguity remains for type inference -- only IB.Item remains available for implementation by B_From_A.IB.Item .

Edit

For understanding the underlying mechanism, it is important to know that there are two different approaches of implementing a hierarchy of interfaces in F#:

// ----- A hierarchy of interfaces
type IFoo = abstract FooMember: int

type IBar =
    inherit IFoo
    abstract BarMember: int

// Approach 1: Implement IFoo "explicitly".
// In the object browser, you will see both IFoo and IBar as parents of FooBar.
type FooBar =
    interface IFoo with member this.FooMember = 0
    interface IBar with member this.BarMember = 0

// Approach 2: Implement IFoo "implicitly" (as part of IBar).
// In the object browser, you will only see IBar as parent of FooBar.
type FooBar =
    interface IBar with
        member this.FooMember = 0
        member this.BarMember = 0

Now, if both IFoo and IBar were to have a member with the exact same signature (eg, as in your example, an Item property accessor), and you implemented the member only via FooBar.IBar.Item , then a type inference ambiguity would necessarily arise, because it would be undefined behavior whether FooBar.IBar.Item should implement IBar.Item or IFoo.Item .

As a consequence, the answers to your questions are:

• "...why it works in this particular way": See above
• "Is it by design": Yes, and also see @John's answer.
• "Why the type B_from_A doesn't see that the slot for IA.Item is already implemented by the parent A ": Your premise is incorrect. The compiler does see it, but it cannot know whether B_from_A.IB.Item should
  • reimplement the (in A) already-implemented IA.Item , or
  • implement IB.Item
• "But then it allows only partial implementation of IA , so it actually sees that SharedMethod is already implemented in the parent." As stated above, it sees that both IA.SharedMethod and IA.Item are already implemented by the parent A , but the ambiguity is not related to "seeing or not seeing" any pre-existing implementations in A .