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

Alex Rønne Petersen xtzgzorex at gmail.com
Sun May 13 09:41:58 PDT 2012


On 13-05-2012 18:39, 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.
> (It's also been stated somewhere that they should be pure and nothrow,
> or something like that, but I forget where.)
>
> This makes it a nightmare to use const objects in data structures, 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.
>
> 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?
>
> Stewart.

I agree with everything but toString(). I'm afraid that forcing 
toString() to be const will have harm flexibility severely. Can't we do 
better, somehow?

-- 
- Alex


More information about the Digitalmars-d mailing list