Does (or will) C# include features for side-effect

Question

I know C# is getting a lot of parallel programming support, but AFAIK there is still no constructs for side-effects verification, right?

I assume it's more tricky now that C# is already laid out. But are there plans to get this in? Or is F# the only .NET language that has constructs for side-effects verification?

Answer 1

Not only is there nothing for side-effect verification - there's nothing even to verify that a type is immutable, which is a smaller step along the same route IMO.

I don't believe there's anything coming down the pipe in C# 4.0 (although I could easily be wrong). I really hope that immutability makes an impact in C# 5.0; certainly Eric Lippert has blogged quite a bit about it, and folks at MS have been thinking about parallelism a fair amount.

Sorry it's not a more encouraging picture.

Edit: Judah's answer is considerably brighter... would framework support be good enough for you? :) (I wouldn't be entirely surprised if some aspects of Code Contracts weren't ready for .NET 4.0, mind you - if perhaps they kept the initial release relatively small and boosted it later.)

Answer 2

C# the language isn't, but .NET the framework may be.

The Contracts library + the static analysis tools being introduced in .NET 4 might introduce these:

Microsoft is using [Immutable] and [Pure] inside .NET 3.5 framework right now.

For example, see [Microsoft.Contracts.Immutable] and [Microsoft.Contracts.Pure] inside .NET 3.5, in the System.Core.dll. Unfortunately, they're internal. However, Microsoft.Contracts.* is mostly born out of Spec# research, and Spec# has been folded into the Contracts APIs that will be part of .NET 4.0.

We'll see what comes of this. I haven't checked to see if the pre-release .NET 4.0 bits contain any APIs like [Pure] or [Immutable] in the Contracts APIs. If they do, I'd imagine the static analysis tool will be the one to enforce the rule, rather than the compiler.

edit I just loaded up Microsoft.Contracts.dll from the latest pre-release drop of MS Code Contracts this week. Good news: [Pure] and [Mutability(Mutability.Immutable)] attributes exist in the library, which suggests they will be in .NET 4.0. Woohoo!

edit 2 Now that .NET 4 has been released, I looked up these types. [Pure] is still there in System.Diagnostics.Contracts namespace. It's not intended for general use, but rather, for use with the Contract API's pre- and post-condition checking. It is not compiler enforced, neither does the Code Contract checker tool enforce purity. [Mutability] is gone. Interestingly, where Microsoft was using Mutability and Pure attributes in .NET 3.5 (in the internal BigInteger class in System.Core.dll), .NET 4 has moved BigInteger into System.Numerics, and has stripped the [Pure] and [Mutability] attributes off that type. Bottom line: it appears .NET 4 does nothing for side-effects verification.

edit 3 With the recently (late 2011) previewed Microsoft Rosyln compiler-as-a-service tools -- believed to be scheduled for RTM in Visual Studio 2015 -- look like they'll be able to support stuff like this; you could write extensions to the compiler to check for purity and immutability, and issue compiler warnings if something decorated with those attributes don't follow the rules. Even so, we're looking at a few years out to support this.

edit 4 Now that Rosyln is here as of summer 2015, the ability to build a compiler extension for pure/immutability does indeed exist. However, that doesn't do anything for existing framework code, nor 3rd party library code. But on the horizon is a C# 7 proposal for immutable types. This would be enforced by the compiler and would introduce a new immutable keyword to C# and a [Immutable] attribute in the .NET framework. Usage:

// Edit #4: This is a proposed design for C# 7 immutable as of June 2015.
// Compiler will implicitly mark all fields as readonly.
// Compiler will enforce all fields must be immutable types.
public immutable class Person
{
    public Person(string firstName, string lastName, DateTimeOffset birthDay)
    {
        FirstName = firstName; // Properties can be assigned only in the constructor.
        LastName = lastName;
        BirthDay = birthDay; 
    }

    public string FirstName { get; } // String is [Immutable], so OK to have as a readonly property
    public string LastName { get; }
    public DateTime BirthDay { get; } // Date is [Immutable] too.
}

edit 5 It's November 2016, and it appears immutable types were dropped from C# 7. There's always hope for C# 8. :-)

edit 6 It's November 2017. C# 8 is coming into full view, and while we won't have pure functions, we will have readonly structs. This makes a struct immutable, which allows several compiler optimizations.

Answer 3

In principle, verifying whether something is immutable & whether the code lacks side-effects is easy. All fields of the class/data structure must be readonly and their type must be another immutable object. We'd also need a way for marking a delegate as "pure" (side-effect free), but that would probably all be possible.

However, the problem is that this is often too restrictive. In F#, you'd generally write the code in a side-effect free & immutable style, but it is often beneficial to use some mutation locally. This doesn't break the overall purity (in some sense) and makes it much easier to write the code. However, verifying this automatically is difficult (meanin that it's an interesting theoretical problem..)

For example, it's perfectly fine to work with arrays in a "pure" way. You can have methods like Array.map that apply some function to all elements and return a new array without modifying the original one. The function mutates the (newly created) array before returning it, but the array isn't mutated anywhere else, so this is in principle pure, but hard to verify (and this is quite useful programming pattern in F#).

So, I think there is a lot that could be done, but simply banning all side-effects may not be as good way as it appears to be. The nice thing about contracts is that they could be probably used in this scenario as well.