Create FS-1073-record-constructors.md

[charlesroddie]

No description provided.

[dsyme]

Adding a few issues to take note of

[dsyme]

Please add the following unresolved questions

• Should this form be usable in pattern matching?

• Should named arguments be accepted? Is there a way to make the use of named arguments mandatory so that changing field order will not break client code?

• There is a potential future interaction with optional record fields. In many ways, this proposal makes optional fields in records much more palatable since the existing optional argument syntax can be used. We should just note the potential interaction and give a link to the suggestion for optional entries in records

• Can the record names be used as first class function values?

• There is a potential for a breaking change for this kind of code:

type R = { a: int }
let R x = { a = x }

In this case the second R should take precedence over the first R

• There is also a potential for a (less serious?) breaking change when a module containing such a R is opened out-scoping another R definition, e.g.

module M1 = 
    let R x = { a = x }

module M2 = 
    let Q x = x + 1
    type R = { a: int }

open M1
open M2

R 3

Note the second open M2 might now bring a different R into scope. We would have to find a resolution for this I think as it is definitely possible that it would affect existing code. I suppose the resolution would be to prefer any other R over the type name.

[charlesroddie]

Should this form be usable in pattern matching?

This makes it a larger request but I'll include that.

Should named arguments be accepted?

Yes. Added a section making it clear that this is already the case.

Is there a way to make the use of named arguments mandatory so that changing field order will not break client code?

This sounds like a larger .Net suggestion. It's actually less relevant to records than other types because records have the standard F# record syntax which already enables this.

There is a potential future interaction with optional record fields...

Done

Can the record names be used as first class function values?

Covered by a separate issue.

There is a potential for a breaking change

Added

[smoothdeveloper]

Is there a way to make the use of named arguments mandatory so that changing field order will not break client code?

There is a suggestion for this:
fsharp/fslang-suggestions#414

[dsyme]

Thanks!