Allow ValueOptions to be used as optional parameter types

[Happypig375]

I propose we allow:

type C(?a) =
    let b = defaultValueArg a 2 // Error here
    member _.B = b

error FS0001: This expression was expected to have type
    ''a voption'    
but here has type
    ''b option'    

The existing way of approaching this problem in F# is using reference options.

Pros and Cons

The advantages of making this adjustment to F# are

1. More structs, less GC pressure
2. Allows for more optimisation
3. In line with recent changes to allow ValueOptions to be used as active pattern return types

The disadvantage of making this adjustment to F# is that existing code ?a will have another potential type for all of us to learn about.

Extra information

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

Related suggestions: all are ValueOption parity features.

• Struct representation for active patterns [ RFC FS-1039 ] #612
• ValueOption parity with options #703
• Add List.chooseV, Seq.tryPickV, etc. for ValueOption #739

Affidavit (please submit!)

Please tick this by placing a cross in the box:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• 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:

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

For Readers

If you would like to see this issue implemented, please click the 👍 emoji on this issue. These counts are used to generally order the suggestions by engagement.

[cartermp]

Yep, to me this is a "can't see why no" sorta deal

[charlesroddie]

There should be a way to do this yes. I don't think ?a:int syntax should be used as that is the syntax for options. (And disambiguation is important not only to minimize ambiguity but also because it is important to be able to write fully-annotated F# code where a reader doesn't need to do type inference or read subsequent lines to understand the meaning of a given line.)

Perhaps type C(??v:int) or type [<StuctOptionalArguments>] C(?v:int).

Semi-related: it's curious that DefaultParemeterValue(ValueNone) doesn't work. It would be good for defaults to match C# by allowing not only constant expressions but also default struct values including ValueNone and parameterless struct constructors.

[Tarmil]

I think it could be argued that it's not too bad for readers to not be able to tell if ?a:int is an option or a voption, because from a user's point of view, you still call it the same way. But this point is moot, because no amount of type inference can tell even the compiler whether this should be an option or a voption:

type IMyInterface =
    abstract M : ?a:int -> unit

So we do need a separate syntax indeed.

Semi-related: it's curious that DefaultParemeterValue(ValueNone) doesn't work.

Well, since the tag for ValueNone is 0, it's equal to Unchecked.defaultof<T option>. So you don't need DefaultParameterValue: Optional is enough.

[dsyme]

I've marked this approved-in-principle. It would be great to have it implemented

[charlesroddie]

This suggestion is contained in the RFC https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-1104-struct-representations.md

[dsyme]

Yup, the best proposal in that RFC is really [<Struct>] ?x : int I think, seems natural all in all. I don't think struct ?x: int flies.