Getting the const-correctness of Object sorted once and for all
Stewart Gordon
smjg_1998 at yahoo.com
Mon May 14 03:50:55 PDT 2012
On 13/05/2012 23:50, Jonathan M Davis wrote:
<snip>
> Caching and lazy
> evaluation _will_ be impossible in those functions without breaking the type
> system.
Unless stuff is added to the type system to accommodate it.
For example, a type modifier that adds a "set" flag. When unset, a const method cannot
read it (to do so would throw an AssertError or similar), but can assign to it, at which
point it becomes set. When set, it acts just like any member (non-const methods have
read-write access, const methods have read-only access, etc.). Non-const methods can also
unset it, which they would do if they change the state of the object in a way that
invalidates the cached value.
Alternatively, you could argue that it's the compiler's job to implement caching as an
optimisation for pure methods. But it would have to implement the logic to decache it
when relevant state of the object changes, which could get complicated if you want to do
it efficiently.
> Anything that absolutely requires them will probably have to either
> have to break the type system or use _other_ functions with the same
> functionality but without those attributes.
<snip>
I think that's half the point of std.functional.memoize - to be such a function for you to
use when you want it.
Stewart.
More information about the Digitalmars-d
mailing list