Getting the const-correctness of Object sorted once and for all

[Timon Gehr]

On 05/13/2012 06:39 PM, Stewart Gordon wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1824
>
> This has gone on for too long.
>
> Object.toString, .toHash, .opCmp and .opEquals should all be const.

No, please.

Transitive enforced const + OO -> epic fail. (especially for unshared 
data, which is the default and most common)

The lack of head-mutable class references does not make this any better.

I'd rather keep the current state of affairs than blindly mark the 
existing methods const. Caching/lazy evaluation is everywhere. One 
single lazily cached class member implies that all of the relevant 
methods cannot use that member. What if they have to? They certainly 
have to!

Const/immutable are great for simple value-types. Classes can contain 
immutable values as fields.

> (It's also been stated somewhere that they should be pure and nothrow,
> or something like that, but I forget where.)
>

Similar concerns apply for them (but less so than for const). I don't 
want to have to violate the type system to get basic stuff done in 
OO-ish style! Forced const invariants are annoying enough already.

> This makes it a nightmare to use const objects in data structures,

Why on earth would you want to do that?

> among other things, at best forcing the use of ugly workarounds. There are
> probably other, more serious effects of this that can't easily be worked
> around.
>

I wouldn't bet on that. Marking the methods const, on the other hand, 
certainly would have serious effects.

> It seems that the main obstacle is rewriting the relevant methods in
> std.stream. The current implementation doesn't make sense anyway -
> reading the entire contents of a file is certainly not the way to
> generate a hash or string representation of the stream. I'm thinking the
> hash should probably be the stream handle, and the string representation
> could perhaps be the full pathname of the file. Of course, what it
> should be for non-file streams is another matter. (This would be a
> change at the API level, but when the API's as fundamentally flawed as
> this....)
>
> Are there any other bits of druntime/Phobos that need to be sorted out
> before these methods can be declared const/pure/nothrow once and for all?
>

Almost _all_ of Phobos would have to become const "correct", and it 
cannot, because 'const' is an over-approximation and there is no 
const-inference. const on the top-class interface invades _everything_.

Marking the methods const would break every non-trivial D program out 
there and put programmers in a frustrating straitjacket.