Pure functions in C#
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.)
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?
Why is const-correctness specific to C++?
Const correctness provides two notable advantages to C++ that I can think of, one of which makes it rather unique.
- It allows pervasive notions of mutable/immutable data without requiring a bunch of interfaces. Individual methods can be annotated as to whether or not they can be run on const objects, and the compiler enforces this. Yes, it can be a hassle sometimes, but if you use it consistently and don't use
const_castyou have compiler-checked safety with regards to mutable vs. immutable data.
- If an object or data item is
const, the compiler is free to place it in read-only memory. This can particularly matter in embedded systems. C++ supports this; few other languages do. This also means that, in the general case, you cannot safely cast
constaway, although in practice you can do so in most environments.
C++ isn't the only language with const correctness or something like it. OCaml and Standard ML have a similar concept with different terminology — almost all data is immutable (const), and when you want something to be mutable you use a different type (a
ref type) to accomplish that. So it's just unique to C++ within its neighboring languages.
Finally, coming the other direction: there have been times I have wanted const in Java.
final sometimes doesn't go far enough as far as creating plainly immutable data (especially immutable views of mutable data), and don't want to create interfaces. Look at the Unmodifiable collection support in the Java API and the fact that it only checks at run time whether modification is allowed for an example of why const is useful (or at least the interface structure should be deepend to have List and MutableList) — there is no reason that attempting to mutate an immutable structure can't be a compile-type error.
Code Contract should provide such a feature in the future. Currently, you can mark a method as
[Pure], which means it doesn't have any side-effects (i.e. doesn't modify any of the class members). Unfortunately, the current version of the tools does not enforce this rule, so using that attribute is for documentation purpose only. I'm pretty sure that in future version, it will be enforced via static-analysis (i.e. at compile-time), or at least that's what the documentation hints at.
Related SO questions: Pure functions in C#
What keywords/tools are there to help the compiler optimise
The list of 18 performance related issues it detects is here.
It does not, however, detect the specific example you mentioned.
const is a way for you to express something. It would be useful in any language, if you thought it was important to express it. They don't have the feature, because the language designers didn't find them useful. If the feature was there, it would be about as useful, I think.
I kind of think of it like throw specifications in Java. If you like them, you would probably like them in other languages. But the designers of the other languages didn't think it was that important.