Anonymous Type Mutable Fields / Properties

[juliusfriedman]

Vb.net has the ability to do this with the lack of the Key keyword where as C# does not even though we have always had the ref keyword.

This makes porting code directly both cumbersome and error prone if your not familiar with the semantics and caveats associated.

Proposal would be to emit the cil just as a plain field or ref field to the compiler generated type with the use the special keyword in the code declaration syntax to signal that to c# the compiler.

new{ ref Id=0l,ref ValueString=""}

And also, now that we have ref fields perhaps ref ref could signal that as well.

As an alternate I would possibly suggest the keyword field or mutable, i.e. field Id=0 and field ref Id=0; or mutable Id=0 although I feel that is slightly more verbose.

[HaloFour]

dotnet/roslyn#11421

The design of anonymous types in VB.NET is quite different from that of C#. For starters, every member is mutable by default. If you want a member to be immutable and to participate in the identity of the instance that member must be marked with the Key keyword.

Given tuples now exist in the language and the members are mutable it's questionable as to whether mutability in anonymous types would be that valuable. In fact it could be dangerous given that anonymous types are reference types and subject to sharing state.

[juliusfriedman]

Updated my proposal and thanks for the link.

Understood on the dangers and that aside, just a proposal.

I was porting some code where both inline struct declarations and other types of assignments were present and while definition of the type (either explicitly or with the use of a Tuple) is a better practice in .Net I feel that for those who know what we are doing it's a helpful syntactic sugar akin to lambda properties.

I also am quite sure that this addition as proposed is very small and easy to implement as outlined and causes NO changes to the JIT or CLR nor are there any backwards compatibility concerns except for old compilers dealing with new syntax which in this case is the added keyword and assignments to the fields.

This would be handled by emitting an Obsolete attribute in addition to the modopts which is used elsewhere for binary compatibility where the types are used that concern such but would obviously prevent the newer code from compiling on a legacy compiler however this effect is the same as if lamba methods are used in compiler where they are unsupported... or the same can be said for if generics were not supported etc.

In closing Span could be dangerous as well as a lot of other things in InteropServices but if used correctly then the liability approaches 0.