-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow attributes for anonymous records #1192
Comments
(Looks like you missed some sections from the issue template…. Specifically the ‘related’ section, checkboxes and voting para.) Related:
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 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. |
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. I totally understand the potential reluctance to add this in - slippery slope etc. - but it would a very nice to have. |
We should move in the opposite direction. If you use a |
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? |
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? |
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. |
Duplicate of #886. REsolution is "use a regular record type" |
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
The text was updated successfully, but these errors were encountered: