(I’m taking risks with such a title )

During yesterday computer science practical session (just think of the most hellish thing you have ever done), I was wandering lazily in the program list of the computer where I was supposed to do Excel stuff (actually I had pretty most finished and I wasn’t really in the mood to do extra work), when I found an antique DevC++ installation in one of the menu. Launching the thing I started to do a calculator (yes, after VBA almost anything else to program sounds interesting) when I remembered the use of the const keyword applied to functions and methods which (C++ purists correct me if I’m wrong) compiler-check that the code inside the function/method doesn’t modify both the parameters or the internal class state.

After thinking about it I thought : « Hey actually that’s a nice idea » and indeed it somehow lessens what the functional enthusiasts may call one of the ‘imperative nightmare’, namely, the imperative’s side-effects :

« Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data. It emphasizes the application of functions, in contrast with the imperative programming style that emphasizes changes in state.« .
Wikipédia, Functional programming

This feature is particularly important in the today context where search for performance leads to parallel programming, a field where functional language excels by using this feature that imply that every function calls are independent from the execution context of the program.

IMHO this could proves to be a good feature in C# : a compiler-enforced mean to behave in a (mimicked) functional way with readonly access to fields and parameters and, thus, both no pollution of the others class’ methods call and the absence of locks which would allow, for example, auto-parallelism by the runtime. Especially when C# tends to get more and more functional concepts integrated both in the core language and in the class library.