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

Jonathan M Davis jmdavisProg at gmx.com
Sun May 13 15:50:42 PDT 2012


On Monday, May 14, 2012 00:30:09 Timon Gehr wrote:
> 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.

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 transivity. Caching and lazy 
evaluation _will_ be impossible in those functions without breaking the type 
system. Anything that absolutely requires them will probably have to either 
have to break the type system or use _other_ functions with the same 
functionality but without those attributes. In some cases though, providing 
overloads which aren't const, pure, etc. should work though.

If you want it to be otherwise, you're going to have to convince Walter, and I 
think that it's pretty clear that this is the way that it's going to have to 
be thanks to how const et al. work.

- Jonathan M Davis


More information about the Digitalmars-d mailing list