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