Allow the record pattern to be implemented explicitly

[baronfel]

Submitted by Don Syme on 3/21/2014 12:00:00 AM
25 votes on UserVoice prior to migration

People sometimes find it hard to transition from records to class types - something which comes up when seeking to encapsulate some of the details of the record type. One particular reason for this is because their codebase may uses copy-and-update on record types. One approach to easing the transition would be to support copy-and-update on class types, as long as the class type follows a particular design pattern.

One pattern-based approach could permit both normal record syntax and copy-and-update syntax, e.g.

[<RecordSyntax>]
type R(a:int, b:int) =
    member x.A = a
    member x.B = b
    member x.C = f(a,b)

{ a = e1; b = e2 } --> R(a=e1,b=e2}
{ r with a = e1} --> R(a=e1,b=r.B)

Whether there were one or two attributes (one for 'RecordSyntax' and one for 'CopyAndUpdateSyntax') would be up for discussion. Presumably using either attribute would give result in a declaration-time check that members exist to match constructor arguments. Matching uppercase properties to lowercase argument names is somewhat inelegant but in the balance is likely to be a reasonable price to pay for following .NET and F# design norms.

Original UserVoice Submission
Archived Uservoice Comments

[dsyme]

I've renamed this, see also #1152

[kerams]

Would the attribute imply structural equality, would such a class otherwise be indistinguishable from a bona fide record?

[dsyme]

Would the attribute imply structural equality, would such a class otherwise be indistinguishable from a bona fide record?

The type would have to implement the equality/comparison interfaces