[RFC FS-1331] - Allow opens in type and expression scopes

[ijklam]

• Suggestion
• Implementation

[ijklam]

I am a bit wanna to make the type-scoped opens must to be the first part of a type definition, or remove it, due to the complexity of the typechecking on types.

On current prototype, the type-scoped opens can be applied to all members and vals and interface, including the definition section of record/union/exceptions.

type ABC2() =
//    inherit Object()                     // cannot find Object here
//    let maxValue = Int32.MaxValue        // cannot find Int32 here
    [<DefaultValue>] val mutable minValue: Int32
    member _.Write x = Console.Write (x: string)
    interface IDisposable with
        member this.Dispose (): unit = raise (NotImplementedException())
    open System

type A = 
  | A of Int32            // can find Int32 here
    with
        open System

[brianrourkeboll]

Interesting. I guess that's because some parts of type definitions implicitly have recursive scope while others don't?

[ijklam]

The typechecking to fields, structural fields, interface ... with are separate, it doesn't know the order of opens when typechecking them, therefore we can only take all opens out, apply to the env, and pass it to the typecheck functions.

The opens are always putted before members because of the pre-process to auto properties. Only typechecking lets can keep the order of opens.

I don't like the current type-scoped opens, as it is not following the up-to-down order. And by having these restrictions, it seems less useful.

[T-Gro]

I support the restriction - in a type definition, allow opens right below the beginning of a type.

The examples you have shown - symbols being available even when open System comes later - breaks my natural top-to-bottom reading habit for F# code.

Even if in types it is limited at the beginning of a type only, its important that it still works for any expression body within that type - that works, right?

[ijklam]

Yes. I will make type-scoped opens must at the beginning of type definition.

[ijklam]

I managed to make the type-scoped opens can be applied following their declaration order, but if there are auto properties, things will be weird again. For example,

type A() =
  member _.B  () = Int32.TryParse "1"         // line 2    // can access Int32 before open System
  open System                                 // line 3
  member val C: Int32 = 11 with get, set      // line 4

This is because the code above will be desugar as

type A() =
  let mutable ``C@`` : Int32 = 11             // line 4
  member _.B  () = Int32.TryParse "1"         // line 2    // can access Int32 before open System
  open System                                 // line 3
  member _.C with get(): Int32 = ``C@`` and set v = ``C@`` <- v     // line 4

The open System will be applied to the environment while typechecking let mutable ``C@`` = ..., as it has same range (on the line 4) as member val C, making member _.B ... (on the line 2) can also have access to System.

Therefore I am wondering if we can implement the limitation mentioned in the spec 8.13.2 Auto-implemented Properties, to make all member vals appear before any other member, but after let or do bindings? Though this is a breaking change.

Automatically implemented properties are part of the initialization of a type, so they must be included before any other member definitions, in the same way as let bindings and do bindings in a type definition.

[ijklam]

Just realized that the auto properties can also be placed in interface implementations. If we implement that limitation, it will be another breaking change.

[T-Gro]

We could do it as a warning, but not as a hard error if such code is allowed now - possibly a deprecation and erroring later.

[T-Gro]

If this could be enforced ONLY if people want to opt in type-scoped open, we would have the benefit of:

• Not breaking existing code
• Ensuring that users of open use it in a legit way