Congratulations to the D Team!

[H. S. Teoh]

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