Public [<Literal>]s as static members

[Happypig375]

I propose we allow public [<Literal>]s as static members.

The existing way of approaching this problem in F# is forcing to define the [<Literal>] in global level or in a module.

e.g.

[<Struct>] type UserID = private UserID of int
    with [<Literal>] static member Maximum = 9999 //error currently, should allow

type ``THREE!!!!!!!!!``() = 
    [<Literal>]
    let privateLiteral = 3 //currently allowed
    [<Literal>]
    static member PublicLiteral = 3 //error currently, should allow

Pros and Cons

The advantages of making this adjustment to F# are

1. one more parity with C#
2. make literals more first class

The disadvantage of making this adjustment to F# is implementation effort required.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): S

Related suggestions: (put links to related suggestions here)

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• [x] This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• [x] I have searched both open and closed suggestions on this site and believe this is not a duplicate
• [x] This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it.

Please tick all that apply:

• [x] This is not a breaking change to the F# language design
• [x] I or my company would be willing to help implement and/or test this

[charlesroddie]

Agree. This would give better scoping.

[cartermp]

I also agree that this should be allowed, especially since you can already put them in modules.

[dsyme]

I marked this approved in principle

[spoilerdo]

Any progress??

[vzarytovskii]

Any progress??

I don't think anyone started working on it yet unfortunately.

Contributions are welcome though, if you'd be interested in implementing it.

[abelbraaksma]

Yes, we should probably make an RFC for this. Though before we do that, we may need a bit of discussion on what syntax we should support. I'm not so keen on allowing [<Literal>] on static member, as it isn't really a member of the class. In C#, for instance, you cannot declare a const static, as that is implied.

Currently, [<Literal>] applies to let and only to let, and this is already allowed inside a class. My proposal would be to simply allow the let in a class to be public, which would automatically allow class-scoped literals to be public as well. Since let can already be static, we should probably only allow [<Literal>] public static let X = 42, as it makes no sense to have a literal that requires an instance of a class. Likewise, we could opt to disallow static and make that implied, but for readability, requiring it makes perhaps more sense.

Obviously, a literal with static let mutable X = 42 should be disallowed.

The question that remains, though, is whether or not we seize the moment and allow public let for non-literals as well. My guess is that it would be simple to allow once we open it up for literals, but there'll be some overlap with val. The main difference being that val cannot be instantiated at declaration, and let cannot be assigned to in the constructor or anywhere, unless mutable.

[charlesroddie]

allow public let for non-literals as well

This is my suggestion https://github.com/fsharp/fslang-suggestions/issues/811 . Doesn't seem to be very popular.

[abelbraaksma]

@charlesroddie, thx for pointing me to that. Though there's one big difference, I don't suggest to turn public let into a property with a backing field, I suggest it to basically work the same as it is now (it currently creates an internal field), but instead make that field public, so as to open up the possibility to create public literals on classes.

But yeah, I see the overlap with val and I can see from that threat how it might be contentious.