Mutable and immutable anonymous types, and keys

About a month ago, the C# team announced that they were making anonymous types immutable in C# 9.0. The issues with mutable anonymous types are pretty well described in Sree’s blog entry, but what it boils down to is this: in several places in LINQ, anonymous types are used as keys for things like grouping and filtering. For example, if you group customers by state and country, then the grouping is done on a composite key made up of the State field and the Country field in an anonymous type. To enable keys to be used to do grouping efficiently, they have to expose a stable hash value. That is, once a key has been constructed, it always needs to return the same hash value.

The problem was that anonymous types base their hash value on the hash values of the constituent members of the type. If those values are mutable, then that means that the hash value is mutable. Which means that the hash value might not be stable, which means that it might be possible to really hork up LINQ queries by accidentally changing keys during an operation.

In looking at this problem, though, we didn’t want to throw the baby out with the bathwater. Anonymous types are somewhat limited at the moment because they cannot be named, but you can use late binding to work with them even outside of the context in which they were declared. And future features that we’re interested in exploring, such as nominal anonymous types and dynamic interfaces, may make anonymous types even more useful. As such, it seemed too drastic to simply make them immutable, especially because this would be a one-way decision–once they were immutable, compatibility would make it extremely difficult to make them mutable again in the future if it become more desirable to do so.

At the same time, it occurred to us that the problem we’re dealing with here–generating hash values–is one that applies to many situations, not just anonymous types. Generating hash values is a common operation for types, and making it easier to do that right seemed to be a win. So instead of changing the way anonymous types work, we’ll be introducing in Beta 2 a way to more easily generate a correct hash value from a type. For Orcas, this will be limited to anonymous types, but beyond Orcas, we’d like to generalize this to all types.

In Beta 2, you will be able to specify a Key modifier on a field of an anonymous type (i.e. “New With { Key .Country = “USA”, Key .State = “WA” }”). This modifier will do two things: one, it will make the field read-only (since keys have to be stable), and two, it will cause GetHashCode to be overridden and call the GetHashCode of the key field. You can have as many Key fields as you like, and the hash codes of all the keys will be combined. The LINQ query expressions will automatically use Key fields in any situation where a key is going to be generated (for example, Group By), but you will need to include the Key modifier if you are calling the LINQ APIs directly. Post-Orcas, we’d like to generalize this concept to all types and allow you to declare Key properties or fields, and do the same thing as with anonymous types. This will, we hope, simplify the work of making types that can be easily hashed.

11 thoughts on “Mutable and immutable anonymous types, and keys

  1. Pingback: @ Head

  2. Matt Warren

    The real problem with mutable types and hashcodes was not any interference with LINQ, but with Hashtables/Dictionaries and DataBinding. If the anonymous types were data-bound and the fields were allowed to be editted the ‘hashcodes’ would change to make the new values and the object would no longer be discoverable within the table.

    Reply
  3. Pingback: Jason Haley

  4. Daniel Moth

    I don’t think we have made our messaging clear here. This "Key" functionality described in this post is not mentioned in the older C# post. Is the implementation different in the two languages then?

    Reply
  5. Pingback: Claudio Brotto

  6. Fan

    Oh! You’ve done a great thing!! Generating hashcode is previously a complex work and easily to be done incorrectly.

    I fully support this design.

    Reply
  7. Pingback: The Visual Basic Team

  8. Pingback: Anonymous

Leave a Reply