Why are opEquals/opCmp arguments not in or const for Objects?

[Jonathan M Davis]

On Tuesday, March 19, 2013 01:31:23 Stewart Gordon wrote:
> What I'm suggesting may be inefficient in complicated cases, but that's
> different from being impossible, which is what you're basically saying.

It _is_ impossible if it's in the type, because you can't modify const. Sure, 
in same cases, you can put the data outside the type, but that's often 
undesirable.

> Moreover, all this talk seems hypothetical. I'm yet to see anybody post
> a real-world example of what is being talked about, let alone one that
> will affect the typical everyday D programmer. Having some examples
> would help put the problem in better perspective.

It's been discussed ad nauseum before. Go digging through old threads if you 
want more details. I'm just telling you want the plan is. Requiring opEquals 
and friends prevents certain idioms, and we have no reason to prevent those 
idioms - especially in a systems programming language. And every time that 
we've discussed making any of them const, a number of people have complained 
quite loudly. Some of them have real world code that would be negatively 
affected, but it's not mine, so I don't remember all of the nitty gritty 
details. It's been a big debate for some time how to resolve the problem given 
than some use cases require const and others require mutable. In the last big 
discussion, someone pointed out that opEquals and friends don't even need to 
be on Object in the first place, and that's what we decided on. And we don't 
really lose anything by removing them. Then, just like with structs, classes 
that want opEquals to be const can make it const, and those that don't want 
to, don't have to.

- Jonathan M Davis