I've recorded two TBD items for this RFC:

• Resolve how static classes are defined in F#
• Respect the RequireQualifiedNameAttribute(true) on a static class, which prevents it being opened, or at least gives a warning, as for F# modules.
• Add testing for AutoOpen attribute

Some discussion here too: fsharp/fslang-suggestions#383

I notice C# lets you do this:

using static System.Double;

For some reason I thought it only let you open static classes, but it seems you can open any class. I don't quite like that.

In F# I was planning this:

open System.Math

(note there is no open static), and only for static classes (i.e. abstract, sealed in the underlying IL).

The catch 22 is that if we go with the F# approach of naked open then our autocomplete lists for open System. should really contain all static types, which pollutes the list a little but not too badly (about 20 extra things, though almost none of which you'd want to open)

If we go with the F# approach of naked open PLUS being able to open the static content of anything then the autocomplete list would in theory contain all types, i.e. 400+ items.....

My proposal is that

1. We only allow open on static types
2. We only show auto-complete entries for static types

Do people agree with (1)? It will however mean that the feature doesn't have exact parity with C#....

I think that's a reasonable step and gives the majority of the benefit overall. I imagine if the need for opening particular classes with static members is that great, the handling of opens could be expanded.

... if the need for opening particular classes with static members is that great, the handling of opens could be expanded.

My fear is that we will indeed have to do that, because some important C# DSL API gets shipped without declaring a class static. I don't particularly want to have to reopen this design point....

So an alternative would be

1. We allow open on all types
2. We only show auto-complete entries for static types

but that is also kind of a weird position to end in, since auto-complete is not accurate.

A final option is simply to allow open static in F# but I would find it odd and a bit of a misfit.

Going with 'open on all', filtering auto-complete is something that's entirely FCS-based? So in theory could be behind a toggle/config option? VS/FSAC/etc could ship with that filter-flag set to true and allow folks to opt-in to overloads if necessary.

If we go with the F# approach of naked open PLUS being able to open the static content of anything then the autocomplete list would in theory contain all types, i.e. 400+ items.....

Does autocomplete currently list all available entries? If so, is virtual scrolling / lazy loading an option? Or perhaps only showing the first 50 or so options, which would require typing additional chars to pare the list down.

What's the rationale for open static being odd and a misfit?

Let's not get fancy with completion. Its job should be to just suggest symbols that are in scope; not need to apply special rules atop the language semantics.

What's the rationale for open static being odd and a misfit?

The rationale would indeed be interesting to know. Though I personally would skip the static if possible as it is more in-line with the existing feature of opening modules.

If we go with the F# approach of naked open PLUS being able to open the static content of anything then the autocomplete list would in theory contain all types, i.e. 400+ items.....

Afaics IntelliSense is able to handle that due to its already existing filtering logic:

So is it really that much of a problem?

Btw - on this occasion - IntelliSense suggests everything on the first character, even today:

It doesn't seems to "disturb" anyone too much as nobody reported that afaik.

@dsyme any particular reason why you think it would be a problem listing all types with at least one static member? Is it about non-VisualStudio editors?

The rationale would indeed be interesting to know. Though I personally would skip the static if possible as it is more in-line with the existing feature of opening modules.

I'm not totally opposed to open static.

I think my concern is that open is used for F# modules (which are obviously a lot like static classes), and that people just will get confused by open static for that reason.

I think my concern is that open is used for F# modules (which are obviously a lot like static classes), and that people just will get confused by open static for that reason.

A quick thought: perhaps open type System.Math is actually more idiomatic for F#. This is partly because type is used at the declaration site.... This would also allow open module FSharp.Core.Something if we want.

I'm for just open System.Math. It would be nice if it emitted a warning if the type does not contain any accessible static members.

I've discussed this with @cartermp and we've decided to go with just plain "open", even though the intellisense lists may end up containing additional elements.

Just a random thought: I assume this feature makes types in addition to static members way more viable, maybe even more than we want?

I guess we'll learn over time 🙂

@TIHan note we must also do this:

Note: In the preview nested types are not revealed when opening a static type

Makes sense, we will stop putting the nested types into scope.

Makes sense, we will stop putting the nested types into scope.

@TIHan We should bring them into scope. I think "preview" is not doing this :-)

@TIHan The RFC also needs to be udpated to make it clear that method overload sets are not being combined. I think we adjsuted it to combine them and now need to revert that.

Regarding this example from above by @abelbraaksma, this will call Example2:

Thanks, that clarifies the resolution for generic members. Iirc this is the same rule as for other stuff in F#: last one wins.

@dsyme, we can presently extend a type locally (no warning) or elsewhere (warning). Will static types be following the same rules, or will extensions be prohibited?

@TIHan We should bring them into scope. I think "preview" is not doing this :-)

Ah, oops. I read it backwards :) - Ok, that shouldn't be a problem.

I think we adjsuted it to combine them and now need to revert that.

I don't think we adjusted combining them yet. I had a PR that did allow it, but now we don't need it.

@dsyme, we can presently extend a type locally (no warning) or elsewhere (warning). Will static types be following the same rules, or will extensions be prohibited?

Extensions are permitted

Resolution of three design issues:

1. Consider "open type Namespace.UnionType" and "open type Namespace.RecordType" where

   • "UnionType"/"RecordType" is not RequireQualifiedAccess
   • "Namespace" has not been opened

   For example consider https://github.com/fsprojects/FSharp.Formatting/blob/master/src/FSharp.Formatting.Common/HtmlModel.fs#L4 then

   open  type FSharp.Formatting.HtmlModel.HtmlProperties

   Resolution: Union cases and record field labels should count as static content when processing open type and thus brought into scope..

2. Opening types that contain operator definitions, e.g.

   type C() = 
   
       // What about this?  Is this static content in C#??  
       static member (+) (a,b) = ...
   
   open type C

   This is bad as the name op_Addition is brought into scope, but it wipes out the FSharp.Core.Operators definition of + (known to F# as op_Addition). This means 1+1 no longer resolver.

   In C#, the operator is never directly callable and while op_Addition is brought into scope, the resolution of 1+1 is not changed.

   Resolution: in F# we should omit all static members with an operator name (beginning with op_) from static content when processing open type.

3. Opening types that contain C# style extension members

   Resolution: In this case, extension members are brought into scope

Regarding 2. isn't the same case with global functions?

I mean, if the type defined a sqrt member, wouldn't our "global" sqrt be shadowed and stop working?

I understand it is bad, but it might be that the whole feature is bad in general and it should be used carefully.

@gusty True, I don't quite understand the resolution since it's no different than any component that does this:

module Beef =
    let inline ( + ) x y = x - y
    let inline ( - ) (x, y) = x = y
    
open Beef
    
    
printfn "%d" (1 + 2) // prints '-1' because '+' is resolved from the module
1 - 2 // error, doesn't resolve that way

@dsyme @TIHan why treat operators different just for this feature?

FWIW I do not believe this quibble should keep us from merging this so we can flight it in previews

@cartermp @gusty The huge danger is that C# types with operators are designed for opening, but take no consideration that simply adding a + operator will completely nuke the + operator of F# (where it is completely irrelevant in the C# version of the opening feature).

If the C# feature isn't affecting the resolution of + then I don't think the F# import of that feature should nuke 1+1.

Resolution: Union cases and record field labels should count as static content when processing open type and thus brought into scope..

I don't understand this: the example seems to talk about numeric unions, aka, enums, but the text, also in the rfc, seems to refer to F# unions, aka DU's (note that the rfc has an error in the examples here: it shows open, not open type).

I can see why we bring DU cases into scope, but I don't see a good reason for bringing CLI enum fields into scope: it's long been a tradition that enums (not DU) must use qualified access. I fear that if we change this, it could cause compatibility issues, or confusion, if both a DU (no qualified access) and an enum (previously qualified access) are brought into scope.

I propose to continue requiring qualified access for CLI enums, and only bring DU cases into scope if open type refers to a DU. For CLI enums, it could still bring static methods into scope, not sure on that; just not the fields.