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