 <p>The initial problem stems from the restriction that contracts cannot modify the object they belong to (otherwise, the program might behave differently in debug and release mode). The way the language enforces that restriction is by making the <code>this</code> pointer <code>const</code>.</p> <p>A <code>const this</code> means is that you can't modify the <code>this</code> object's fields, and as for calling methods - those methods themselves must be annotated as <code>const</code>, and the same restrictions apply to the code of those methods. This explains the first error: the contract, which was <code>const</code>, was trying to call a non-<code>const</code> (mutable) method. Since mutable methods are allowed to modify <code>this</code>, and contracts are forbidden to do so, the compiler forbids the call.</p> <p>Because of the transitive nature of D's constness, everything that's accessed through the <code>this</code> pointer becomes <code>const</code>. And, if any of the class fields are reference types, the target of their indirections becomes <code>const</code> too. This is how the type system will forbid modifying anything that can be reached through the <code>this</code> pointer.</p> <p>The implication of this is that if a <code>const</code> method is trying to return a class field (with indirections, such as a class type like <code>Node</code>), the returned type must also be <code>const</code>. This is the source of the second error message: the return expression attempted to convert the <code>const Node</code> value, obtained through the <code>const this</code>, to a mutable <code>Node</code>. Currently, the syntax <code>@property const Node sub()</code> indicates that the method itself is <code>const</code> (and has as <code>const this</code>), not the return type.</p> <p>Now, generally, in C++, an object with proper constness support will usually have multiple overloads for the methods which return a class field: <code>const</code>, and non-<code>const</code>. The <code>const</code> versions will return a <code>const</code> reference; the non-<code>const</code> will return a non-<code>const</code> reference. The two versions are needed to allow obtaining a mutable field reference when we have access to a mutable object, but still allow getting a <code>const</code> reference if we only have <code>const</code> access to the object. Most of the time, the code of the two methods will be identical - only the function signature will differ.</p> <p>This is where D's <code>inout</code> comes in. Specifying it on the method and some of its arguments or return value means that those arguments or return value will have the same constness as that of <code>this</code> (the object being referred to). This avoids code duplication for the simple cases where returning <code>const</code> and mutable values uses the same code.</p> <p>The syntax I used is <code>@property inout(Node) sub() inout</code>. I think it can be written in more than one way, but this syntax is unambiguous. Here, the parens in <code>inout(Node)</code> make it explicit that we apply the attribute on the return value, and not the function, and placing the method (<code>this</code>) <code>inout</code> attribute after the parameter list, like <code>const</code> in C++, unambigously specifies that it applies to the function itself.</p>