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.
