I propose we have a constraint of the form type-parameter : default to restrict the parameter only to types that support zero-initialization, exactly as demanded by DefaultValue. In addition, certain constraints should satisfy this constraint as well, such as unmanaged.

The existing way of approaching this problem in F# is to use stronger constraints (i.e. unmanaged) coupled with Unchecked.defaultof and other ways to bypass safety checks.

Pros and Cons

The advantages of making this adjustment to F# are:

• Fields with [<DefaultValue>] can be of generic types without breaking type safety. For example, this is currently an error:

  [<Struct>]
  type C<'T> =
    [<DefaultValue>]
    val mutable F : 'T

  error FS0444: The type of a field using the 'DefaultValue' attribute must admit default initialization, i.e. have 'null' as a proper value or be a struct type whose fields all admit default initialization. You can use 'DefaultValue(false)' to disable this check

  While one may disable the check, it is not a good solution since then the type could be anything. With the constraint, consumers of the type would be prevented from passing a type that does not satisfy it.

• A checked version of Unchecked.defaultof would be possible. This could be used in various areas, from reflection to serialization, to simplify situations when a default value must be provided.

The disadvantages of making this adjustment to F# are a new constraint to remember, potentially risking breaking changes if existing code adopts it.

Extra information

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

Affidavit (please submit!)

• This is not a question (e.g. like one you might ask on StackOverflow) and I have searched StackOverflow for discussions of this issue
• This is a language change and not purely a tooling change (e.g. compiler bug, editor support, warning/error messages, new warning, non-breaking optimisation) belonging to the compiler and tooling repository
• 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
• I have searched both open and closed suggestions on this site and believe this is not a duplicate

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.