Congratulations to the D Team!

[Timon Gehr]

On 07/10/2012 01:57 AM, Geoffrey Biggs wrote:
> On 10 July 2012 01:02, Timon Gehr<timon.gehr at gmx.ch>  wrote:
>> ...
>> 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.
>>
>> ...
>> 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

Exactly! I don't think that the term 'const correctness' actually
has a meaning in D. It is a C++ term.