Congratulations to the D Team!

[Geoffrey Biggs]

On 10 July 2012 01:02, Timon Gehr <timon.gehr at gmx.ch> wrote:
> 1.
>
> Most code that gives amortized complexity guarantees, eg:
>
> interface Map(K, V){
>     V opIndex(K k) const;
>     // ...
> }
>
> class SplayTree(K, V) : Map!(K, V) {
>     // ???
> }
>
> 2.
>
> - hash table
> - opApply compacts the table if it is occupied too sparsely, in order
>   to speed up further iteration.
> - toString iterates over all key/value pairs by the means of opApply.
>
> Clearly, toString cannot be const in this setup.
>
> 3.
>
> Often, objects can cache derived properties to speed up the code. With
> 'const-correctness' in place, such an optimization is not transparent
> nor doable in a modular way.
>
>
>
>> IME, it rather helps code quality than harm it.
>
>
> I am not talking about code quality. I am talking about code
> maintainability, extensibility and performance.

Although I don't know what D's goals with const are, in C++,
const-correctness is often considered from the perspective of outside
the interface. A const member function guarantees that, from the point
of view of an entity using the object, its state will not change. This
does not guarantee that data stored in the object is not changing.
This allows for things like storing cached values. Unfortunately,
implementing this is more difficult than it might sound, e.g. in cases
such as  #2 above, particularly if you also want the compiler checking
that the const keyword can allow (which you should).

See here for more information:
http://www.parashift.com/c++-faq-lite/mutable-data-members.html

Geoff