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.

Reply via email to