const(Object)ref is here!

[Jonathan M Davis]

On Monday, December 06, 2010 07:37:27 Steven Schveighoffer wrote:
> On Mon, 06 Dec 2010 10:11:30 -0500, so <so at so.do> wrote:
> >> It doesn't work.  obj == obj calls .opEquals(obj, obj), whose signature
> >> is:
> >> 
> >> bool opEquals(Object obj1, Object obj2)
> >> 
> >> So even if you mark a derived instance's opEquals as const, the derived
> >> class is stripped back down to Object before any calls are made.
> >> 
> >> Memoization and lazy calculations are not as important as being able to
> >> compare const or immutable objects.
> >> 
> >> -Steve
> > 
> > This one is a very serious issue.
> > Should changing their signatures to:
> > bool op###(auto ref const Object) const // breaking change but just
> > signature
> > 
> > and addressing "auto ref" enough to fix it?
> 
> auto ref doesn't matter, these are classes, they are always ref ;)
> 
> All that is needed is to make opEquals const (and its arguments const) as
> you say.
> 
> > With a glance to source code, looks like all that is required is just a
> > few lines of change.
> 
> It should be relatively painless.  Just change the signatures of the base
> functions, and fix any compile errors.

And watch all the code break... I'll definitely welcome the change (it's probably 
the first bug that I voted on in bugzilla), but there will be tons of code broken 
by it, since you just _know_ that a lot of user code doesn't bother to make 
toString() and its friends const. It's still a change that needs to be made 
though. Being unable to properly compare const and immutable objects is 
crippling. Of course, it would be more of an issue if it were easier to actually 
create immutable objects which are classes rather than strcuts, but that's a 
separate issue.

- Jonathan M Davis