Allow attributes for anonymous records

[leandromoh]

I propose we support attributes for anonymous records.

The existing way of approaching this problem in F# is define a named type.

without the attribute the code compiles

Pros and Cons

The advantages of making this adjustment to F# are that we could use anonymous type in more situations that make sense.

I can not see any disadvantages.

Extra information

Estimated cost: XS or S

[abelbraaksma]

(Looks like you missed some sections from the issue template…. Specifically the ‘related’ section, checkboxes and voting para.)

Related:

• https://github.com/fsharp/fslang-suggestions/issues/886
• https://github.com/fsharp/fslang-suggestions/issues/712

Anyway, in terms of motivation, have a look here: https://github.com/fsharp/fslang-design/blob/main/FSharp-4.6/FS-1030-anonymous-records.md#design-principle-not-anonymous-object-expressions.

Later in that proposal, you’ll find that specifically CLIMutable is considered. This is going to be quite a big change, certainly not XS/S, as it requires careful consideration and implementation of syntax changes (just my 2p, I may be off).

I’m neither against nor in favor if it, I just never had a need for it. As soon as anon types become more complex I’ve always found that making them nominal is the better way out.

[isaacabraham]

Funnily enough I came on here tonight to suggest something exactly like this for exactly this reason. Anonymous records are very useful for lightweight, transient values e.g. reading from SQL or JSON into a type that matches the source 1:1, from which you can then do standard F# processing to e.g. create a validated value. Unfortunately, many libraries rely on the "parameterless-ctor-with-public-setters" trick to handle this i.e. [<CLIMutable>].

I totally understand the potential reluctance to add this in - slippery slope etc. - but it would a very nice to have.

[charlesroddie]

We should move in the opposite direction. If you use a CLIMutable you should not only have to define a type, but also write an essay apologizing for the use of this attribute.

[cartermp]

Although not called out explicitly, this is likely to fall under the following principle for anonymous records: https://github.com/fsharp/fslang-design/blob/main/FSharp-4.6/FS-1030-anonymous-records.md#design-principle-not-anonymous-object-expressions

I can appreciate that anonymous records being a convenient substitute for a small type declaration that has little meaning beyond its encompassing type sort of falls apart when .NET Interop is concerned. But implementing a capability for the sake of a single use case doesn't feel worth it to me. Are there other attributes scoped to the type declaration that would be handy?

[isaacabraham]

If it wasn't a breaking change, I would have suggested putting that attribute on by default, but I guess that that ship has sailed?

[isaacabraham]

But implementing a capability for the sake of a single use case doesn't feel worth it to me.

Yes, this is my concern, too. It feels very, very specific. But it is a pity without it because the unfortunate truth is that in the .NET world so many serialization / mapping libraries (Dapper, Json etc.) rely on having that ability.

I do wonder how this will change in the C# world with immutable records though.