Compile error from field vs submodule name ambiguity when outside unopened module

[TysonMN]

Over the years, F# has allowed more things to have the same name without getting confused. This issue is about one such situation where F# still gets confused.

Consider the following code.

module Top

module A =
  type B = { C: bool }

  module B =
    module C =
      let x = 0

  let y = B.C.x

let z = A.B.C.x
//      ^^^^^
// Error FS0728 Field 'C' is not static

Expected behavior

I expected the expressions assigned to y and z to evaluate to the same thing.

Actual behavior

As shown in the code as a comment, the actual behavior is a compile error in the expression assigned to z because the B resolves to the type B instead of the nested submodule B.

At the same time, IntelliSense gives the correct tooltip when hovering over x.

But IntelliSense also gives a tooltip that agrees with the compiler when hovering over C.

Known workarounds

Open module A just before z like this.

open A
let z = B.C.x

Related information

• Operating system
  • Edition: Windows 10 Enterprise
  • Version: 1909
  • OS build: 18363.1198
• .NET SDK: .NET Core 3.1.403
• Visual Studio
  • Edition: Enterprise 2019
  • Version: 16.7.7

[TIHan]

Definitely feels like a bug to me, but it might be part of the design.

[TysonMN]

I ran into issue again today and struggled a bit before I remembered that I had already created this issue about it. (This time it involved a discriminated union instead of a record.)

Any chance for progress on this?

[KevinRansom]

@dsyme , how do you want to resolve this ambuiguity?

[dsyme]

Yes, this should resolve. As with B.C.x the inevitable-error of resolving to a field in A.B.C.x should prefer to search module B