Congratulations to the D Team!

[Timon Gehr]

On 07/11/2012 02:39 PM, Andrei Alexandrescu wrote:
> On 7/10/12 10:59 PM, Jakob Ovrum wrote:
>> On Wednesday, 11 July 2012 at 02:02:52 UTC, Andrei Alexandrescu wrote:
>>> On 7/10/12 9:45 PM, Timon Gehr wrote:
>>>> I do not desire logical const as a language feature. But conservative
>>>> type systems are not good for everything. The root of the class
>>>> hierarchy needs to be good for everything. Object is not an adequate
>>>> root any more.
>>>
>>> How about we consider just stiffening that upper lip and implement
>>> comparison and hashing without modifying their target?
>>>
>>> Andrei
>>
>> It's more likely to go down like this: programmer attempts to write his
>> opEquals (or toString etc) within the restrictions of const, but fails
>> due to the requirements of the implementation (which can easily go
>> beyond simple performance measures like caching, as demonstrated). The
>> programmer then writes his own mutable member function and neglects
>> opEquals altogether. If the programmer is real nice, he/she will write a
>> throwing opEquals stub.
>
> I gave evidence on a large, high quality C++ codebase that the use of
> mutable (which is the solution of choice for memoization, caching, and
> lazy computation) is extremely scarce.
>

Unlike in D, in C++ programmers have a choice of declaring a method
const or not const.
Also, what percentage of the usages of 'const' would disappear, without
changing the code in any other way, if

- const was transitive?
- all usages of mutable disappeared?
- the social graph was infinite?
- any combination of the above?

The data given so far is not evidence relevant to this discussion.
(it is not evidence in the traditional sense anyway, because statements
about a closed source code base cannot be validated by a third party.)

> What evidence do you have for your prediction?
>

Attempts to impose restrictions without conceivable benefit always go
wrong at some point. I'd claim this to be general knowledge.

Almost nobody has responded to the RawObject proposal.

Jacob Carlborg has brought my attention to this:
http://www.ruby-doc.org/core-1.9.3/BasicObject.html

I still think that would be the best solution.