Congratulations to the D Team!
Jakob Ovrum
jakobovrum at gmail.com
Wed Jul 11 08:03:17 PDT 2012
On Wednesday, 11 July 2012 at 12:36:43 UTC, Andrei Alexandrescu
wrote:
> I was a long-time proponent of this. It's less exciting than it
> may seem actually.
>
> (a) Classes that work with const just fine incur one extra
> virtual call. I think this can be avoided by having the
> compiler plant the same pointer for the const and non-const
> version in the vtable.
>
> (b) Classes that can't do as little as one of these four
> operations without mutating the object are completely excluded
> from the immutability system, even if they'd otherwise benefit
> from it. Even those that don't "care" they need to actively
> _work_ on not caring, which doesn't sit well.
>
> So I don't see this as a viable solution to people who are fine
> with const, but would like to use e.g. some lazy computation.
>
>
> Andrei
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.
e.g. the LuaD function I posted earlier - it has nothing to do
with caching or lazy computation, it's just that it's only
logically constant and cannot ever be bitwise constant due to the
underlying API. Immutable instances of such structures are next
to useless, as every member function except for a single getter
function uses mutation.
More information about the Digitalmars-d
mailing list