Congratulations to the D Team!

[Jakob Ovrum]

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.