On Monday, 9 July 2012 at 14:59:31 UTC, H. S. Teoh wrote:
On Mon, Jul 09, 2012 at 01:44:24PM +0200, Timon Gehr wrote:
On 07/09/2012 08:37 AM, Adam Wilson wrote:
>Object is now const-correct throughout D. This has been a
>dream for
>many of you. Today it is a reality.
PITA. Forced const can severely harm a code base that wants to
be
flexible -- it leaks implementation details and is infectuous.
[...]
Can you give an explicit example of code that is harmed by const
correctness? IME, it rather helps code quality than harm it.
Besides,
since everything converts to const, it doesn't harm as much
code as one
might imagine (most code will be unchanged except where it
matters --
which IMO is a good thing).
But YMMV.
T
This is like the third time I bring up this example around this
topic, but forcing const harms wrappers of state-machine style
interfaces, which many C libraries use.
Here's LuaObject.opEquals from LuaD:
/**
* Compare this object to another with Lua's equality semantics.
* Also returns false if the two objects are in different Lua
states.
*/
bool opEquals(T : LuaObject)(ref T o) @trusted
{
if(o.state != this.state)
return false;
push();
o.push();
scope(success) lua_pop(state, 2);
return lua_equal(state, -1, -2);
}
This works because LuaObject is currently a struct, but that's an
irrelevant detail, it could just as well be a class in a
different scenario.
This opEquals is only logically constant, not bitwise constant,
hence it must not be const; similar to the caching scenario. Just
trying to demonstrate that the issue is bigger than just caching
- it's any logically constant comparison function.
