Congratulations to the D Team!

[Jakob Ovrum]

On Wednesday, 11 July 2012 at 15:27:55 UTC, Andrei Alexandrescu 
wrote:

> I think I'll find it rather difficult to get behind modeling 
> arbitrary escapes from immutability. If you want classes, you 
> buy into a certain contract with inherent rights and 
> constraints (starting with using references). It's a given, and 
> again I find it unreasonable to ask that classes allow for 
> arbitrary customization.

Some classes don't lend themselves to immutability. Let's take 
something obvious like a class object representing a dataset in a 
database. How is an immutable instance of such a class useful?

The solution to this problem is obvious and right there for us to 
use, the only thing arbitrary here is the limitation we put on 
classes by not using it.

> Your LuaD example goes like this:
>
>     /**
>      * 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);
>     }
>
> You may be able to make this work by putting the state 
> associated with push() and pop() in the Cache subsystem.

Sounds like the kind of workaround people would accompany with a 
nasty comment.

> If all else breaks, have opEquals assert(false, "Call bool 
> lua_equals()").

This is exactly what I was talking about earlier. opEquals failed 
me for no good reason, so I'm begrudgingly going to leave an 
assert behind and give up, writing my own method. As mentioned, 
this has far-reaching consequences for anything that relies on 
opEquals.

> We can't really model every possible design.

No, but apparently we can model this one quite readily.