Compiler allows what looks like a module nested inside of a type, but isn't

[brianrourkeboll]

When defining a type using light syntax (it doesn't matter what kind of type: class, interface, union, record), it is possible to define what appears to be a nested module (at the same indentation level as the rest of the contents of the type), but what actually results in a module defined in the same scope as the type.

https://sharplab.io/#v2:DYLgZgzgPgLgngBwKYAICSAxAhgY1QXgFgAoFMlLAIwhgCdcYUMUQUBLAO0YFoA+driXIoAtgHsAJgFdgqALIoipYeVmMwKABQBKRVu0kS8ZCgDC+xUPIikIyklooA+gDpmOvQGYrZcdNkocgBMlsoqKGooGh74+obExqgAqqHCUCgAgj4o6QBC2X4y8p6p4RFI6haxOvGJKABKpWQA3pksAowAvgWSRYEALE0qkdG61QbEQA===

type IFace =
    abstract F : int -> int
    module M =
        let f () = ()

type C () =
    member _.F () = 3
    module M2 =
        let f () = ()

type U =
    | A
    | B
    module M3 =
        let f () = ()

type R =
    { A : int }
    module M4 =
        let f () = ()

// Etc.
// All modules M, M2, M3, M4 are in scope here.

Using verbose syntax disallows this, as expected.

https://sharplab.io/#v2:DYLgZgzgPgLgngBwKYAICSAxAhgY1QXgFgAoFMlASwDsYkAnMXJE81lLAIwhjtxhQwoQlGigC0APhEwWbMgFsA9gBMArsFQBZFPhQB6PQIDKABhMBGE8ICqVJAA9kOWspQBrJHADuiuq4DkSmoa/iIo8Mgoykhg1BQwFIpUAHQoAKKOSM5IAUhUyqG+KIowABb04YoeKbJyrBr8YCgAFACUOihNbbUoecpAA

type IFace =
    interface
        abstract F : int -> int
        module M = // FS0010: Unexpected keyword 'module' in type definition. Expected 'end' or other token.
            let f () = f ()
    end

// Etc.

Expected behavior

A module nested inside of a type shouldn't compile, or some kind of indentation warning should be given.

Actual behavior

The module is compiled in the same scope as the type.

Known workarounds

Don't confusingly misindent your module definition.

[cartermp]

For this I think it would make sense to emit a warning. I suppose this is considered by design but it's reasonable to warn since the code is kind of wonky.

[auduchinok]

@cartermp @dsyme Would you accept a language suggestion producing errors for these cases? I think making the light syntax work properly (or just in more predictable ways) in more cases is really important.

[dsyme]

@cartermp @dsyme Would you accept a language suggestion producing errors for these cases? I think making the light syntax work properly (or just in more expected ways) in more cases is really important.

Definitely would accept a PR that produces a warning for this case

[cartermp]

Yes, and in the case of an error, a language suggestion would be appropriate.

[auduchinok]

I'd be happy to know if there's any chance for such a suggestion to be approved before filing one. 🙂