Immutability in C# 5?
(Ported from the original post on Mad Props!)
On the latest episode of .NET Rocks, Carl and Richard spoke to Anders about the new release of .NET and C# and what the future might hold. Predictably, Anders revealed that parallelism will be a focus on C# 5, with language enhancements to make use of things like Parallel Linq.
One of the things he spoke about was how difficult it is today to make a truly immutable reference type, with compile checking etc. This got me thinking about how immutability might work in a hypothetical future version of C#, without adding new keywords or language constructs. Immediately the “readonly” keyword sprang to mind.
The readonly keyword is applied to fields in a class. Fields declared as readonly can only be initialized inline or in the type’s constructor. Once they’re initialized, they are, as the name implies, read only.
public class Foo
{
public Foo()
{
Bar = 5;
// Bar can now only be read
}
public readonly int Bar;
}
Imagine if you could declare a class as readonly. All of the class’ fields would have to be declared as readonly too (a bit like the way static classes can only have static members), and its properties would have to have getters only – no setters. Any fields or properties would also have to be either a value type or a similarly read-only reference type, so there was no cheating by changing the property of a property. Let’s mock up a class to see what it might look like:
public readonly class Foo
{
public Foo(int bar, string buzz)
{
Bar = bar;
_buzz = buzz;
}
// this would be fine
public readonly int Bar;
// no setter on our property, so that's fine too
private readonly string _buzz;
public string Buzz { get { return _buzz; } }
// Fizz is a readonly class so this is also fine
public readonly Fizz Fizz;
}
This class would be guaranteed, at compile time, to be immutable. It would be safe to pass around between threads since nobody could change its state. It’d be fine to add methods to it which perform calculations based on the class’ fields and properties, since even they wouldn’t be able to modify the values (they’re all read only too).
I suppose the next step in this evolution would be a way to constrain methods or generic classes to only accept readonly types as their parameters, so that multithreaded code could be guaranteed not to change state. A simple where T : readonly
generic constraint might suffice.
In theory it might be possible to take an existing “non-readonly” class and wrap it dynamically into a read only “proxy” (similar to a mock), but that would be complicated since any reference-type properties would need to be wrapped in a similar way, to prevent users changing their values. Not only that, but any collection property on the class would have to be converted to a ReadOnlyCollection or IEnumerable to prevent it from being modified. It’d be a pretty hardcore piece of code.
I think a way to create a compile-time guaranteed immutable class in C# would be very helpful for people writing massively parallel code. This could be one way to do it … maybe the gurus like Anders have something entirely different in mind. Time will tell!
No new comments are allowed on this post.
Comments
No comments yet. Be the first!