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

Jonathan M Davis jmdavisProg at gmx.com
Sun May 13 19:47:57 PDT 2012


On Monday, May 14, 2012 02:11:21 Era Scarecrow wrote:
> On Sunday, 13 May 2012 at 22:51:05 UTC, Jonathan M Davis wrote:
> > Walter fully intends to require that opEquals, opCmp, toHash,
> > and toString all be const @safe pure nothrow - on both classes
> > and structs. And the reality of the matter is, if that
> > requirement _isn't_ there on classes, then the usage of any of
> > those functions in @safe, const, pure, or nothrow code is
> > seriously hampered - especially const and pure. This has been
> > discussed quite a bit before, and we're pretty much stuck
> > thanks to transitivity.
> 
>   I've been wondering sometimes, if beta builds could be made (but
> not official release builds) that enforce the way it's suppose to
> be, and then we can try to compile against that version and see
> how much difference or how much breaks. The problem may not be
> quite as bad as we think it is.

It doesn't work right now due to issues with druntime and Phobos. For 
instance, format and to!string can't be pure yet due to lower level constructs 
that they use which aren't marked pure. Appender has similar problems. Without 
those, toString really can't be const. I think that there are some issues with 
toHash as well due to the state of the AA implementation in druntime. Some of 
those issues are being addressed, but there's still a ways to go.

But in a way, it doesn't matter how much making those 4 functions const @safe 
pure nothrow will break, because we _have_ to do it. So, what will break, will 
break. When they're made const @safe pure nothrow on Object, it'll 
_immediately_ break code, and there's _no_ way around it. So, at this point, 
I'd say that it's really a matter of figuring out exactly what needs to be fixed 
in druntime and Phobos to make it possible, and once that's been fixed, we 
immediately change Object and and require that those 4 functions have those 4 
attributes. Then everyone can take care of it in their code at once and we 
won't have to worry about it anymore. Lacking a means of phasing it in (like 
we're doing with other stuff like -property), I don't see any other way of 
doing it.

> Honestly I don't see why oEquals,
> opCmp and toHash can't be const (as the data shouldn't change).
> toString and toHash may want to cache it's current result
> (perhaps?).

They can be in almost all cases. The problem is the folks who want to have 
caching and/or lazy initiailization in their classes/structs. You can't cache 
the result of any of those functions (toHash being the main target for it) if 
they're const and pure except in overloads which _aren't_ const, making those 
functions more expensive in comparison to what they could be if they weren't 
required to be const. And lazy initialization becomes almost impossible, 
because if the member variables needed in those functions haven't been 
initialized yet when they're called, then you _can't_ initialize them. If 
getting the value that it _would_ be without actually initializing the member 
variable works, then you can do that if it hasn't been initialized, but if you 
can't do that (e.g. the variable _must_ be set only once), then you're 
screwed. And regardless of whether you can make it work with const, it _will_ 
be less efficient.

So, the folks who really like to use lazy initialization and caching are _not_ 
going to be happy about this. They've complained every time that it's been 
discussed. But that's just one of the costs of const in D. Whether its pros 
outweigh that cost is a matter of opinion.

- Jonathan M Davis


More information about the Digitalmars-d mailing list