Fable: Inherited members shadowing inconsistencies

[runefs]

Description

I had an issue with method shadowing not being consistent with F#. So I tested it in REPL2 and found the particular issue is resolved however I found a different.

Repro code

type a() =
    member x.Foo() = printf "Yeah from A!"

type b() = 
   inherit a()
   member x.Foo() = failwith "Nay from B!"

type c() =
  inherit a()
  member x.Foo() = printf "Yeah from C!"

let bb = b()
let cc = c()
(bb :> a).Foo()
bb.Foo() //should throw but instead calls a.Foo()
cc.Foo() // inconsistent with the above line. This actually calls c.Foo()

code snippet

Expected and actual results

See comments in code

Related information

using the Fable2 REPL

[alfonsogarciacaro]

At the beginning I thought this was related to https://github.com/fable-compiler/repl2/issues/21 but then I tried it with the CLI tool and got the same result. But the funny thing is I got the same result using F# interactive so the problem seems to come from the F# compiler.

What is even funnier is that replacing failwith with printf yields the expected result (everywhere Fable CLI and repl, and FSI). Maybe the F# compiler considers the method is not properly implemented because it just throws? cc @ncave

[ncave]

funny thing is I got the same result using F# interactive

If that's the case perhaps this can be closed and the same issue opened in the fsharp repo.

[alfonsogarciacaro]

@runefs Would you mind reporting this in https://github.com/Microsoft/visualfsharp?

[runefs]

reported

[runefs]

It turns out that it's not a bug, The simple reason is that changing from printf to failwith changes the type inference. In the printf case the inference know the return type to be unit, whereas in the failwith case the return type is generic. Effectively making it Foo() and not Foo() and thus it's no longer shadowing the implementation of Foo() in the base type