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
