fsharp
Allow the record pattern to be implemented explicitly
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
Would the attribute imply structural equality, would such a class otherwise be indistinguishable from a bona fide record?
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
The type would have to implement the equality/comparison interfaces
I believe, since the syntax is relied upon visually, to assume those are implemented on record definition (unless some attributes are put to omit it), we should revise if potential warnings are worthy and can be enabled by default.
For example, when types with RecordSyntax are used with = operator, it should recommend to resort on Object.ReferenceEquals, but there would probably be other similar things to consider for the RFC.
If this is relevant, it should apply the same NoComparison and NoEquality adorned records.
