On Wed, Jul 11, 2012 at 05:27:01PM +0200, deadalnix wrote: > On 11/07/2012 17:03, Jakob Ovrum wrote: [...] > >This solution is not for allowing people to use lazy computation in > >their const overrides, it's for allowing people to still use > >opEquals, toString etc. even if their implementations cannot and > >should not be const. > > > > In this case, they have function that does something else than > compare test for equality, etc . . . The overload make no sense here > in the first place, and the fact that const break such thing isn't a > problem. This is the other way around, the fact that const break > such a practice is good.
It *is* a problem when you're talking about abstractions. If I have million node binary trees and I'm testing for equality, I'd like to be able to cache the results. But being forced to use const means I can't cache anything. And this isn't just about caching; if my tree is partially stored in the database, and I have a DB connection object in my tree class, then I can't use opEquals because I can't modify the DB state (which is impractical if I have to actually use it to make DB queries -- the DB engine may have to cache DB pages, etc.). Any abstraction of opEquals beyond the bitwise level cannot be implemented. In other words, druntime's opEquals is useless in this case. Since const is viral, as soon as one class deep in your class hierarchy needs non-const, your entire class hierarchy is out of luck. Users will have to sidestep the issue by implementing their own version of equality comparison. Which means they have to implement their own version of AA's, because built-in AA's use opEquals, and they have to implement their own version of array comparisons for the same reason, etc.. They will essentially have to rebuild the entire infrastructure provided in druntime. So every user and every library will have their own infrastructure for non-const comparisons, and it will be a major nightmare trying to interoperate between them. All because the single standard, druntime, insists that comparisons must be bitwise const. Sure, it's a good thing, from a theoretical ivory-tower point of view. It's also impractical for non-trivial applications. T -- Many open minds should be closed for repairs. -- K5 user
