Getting the const-correctness of Object sorted once and for all

[Jakob Ovrum]

On Sunday, 13 May 2012 at 17:02:46 UTC, Stewart Gordon wrote:
> On 13/05/2012 17:41, Alex Rønne Petersen wrote:
> <snip>
>> I agree with everything but toString(). I'm afraid that 
>> forcing toString() to be const
>> will have harm flexibility severely. Can't we do better, 
>> somehow?
>
> How exactly?
>
> If you're talking about memoization, it ought to be possible to 
> make use of std.functional.memoize to implement it.
>
> Otherwise, using toString to change the state of an object is 
> bending semantics.  If you want a method to generate a string 
> representation of an object in a way that might do this, then 
> create your own method to do it.
>
> Stewart.

How about logically constant opEquals, toString etc? Currently, 
this is perfectly possible by just *not using const*. Logical 
constancy goes beyond memoization.

For example, take this function:

http://jakobovrum.github.com/LuaD/luad.base.html#LuaObject.opEquals

It cannot be const because Lua instances are state machines. The 
function pushes the this-object to the Lua stack, then it pushes 
the object to compare to, then it uses a Lua API comparison 
function which pops the two objects and pushes the comparison 
result. The result is then popped off the stack and returned as a 
boolean.

The function is logically constant, hence it does not use D's 
const, which should be a completely valid choice to make.