Pure functions in C#

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. I do not believe it's compiler-enforced. [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 verication.

Answer 3

Hi,

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.