Congratulations to the D Team!

[Timon Gehr]

On 07/09/2012 05:00 PM, H. S. Teoh wrote:
> On Mon, Jul 09, 2012 at 01:44:24PM +0200, Timon Gehr wrote:
>> On 07/09/2012 08:37 AM, Adam Wilson wrote:
>>> Object is now const-correct throughout D. This has been a dream for
>>> many of you. Today it is a reality.
>>
>> PITA. Forced const can severely harm a code base that wants to be
>> flexible -- it leaks implementation details and is infectuous.
> [...]
>
> Can you give an explicit example of code that is harmed by const
> correctness?

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.

> Besides, since everything converts to const, it doesn't harm as much code as one
> might imagine (most code will be unchanged except where it matters --
> which IMO is a good thing).
>

Methods do not convert to const.