http://wiki.dlang.org/DIP25

[Steven Schveighoffer via Digitalmars-d]

On 1/8/15 4:04 PM, Meta wrote:
> On Monday, 5 January 2015 at 19:21:38 UTC, Steven Schveighoffer wrote:
>> On 1/5/15 10:05 AM, Meta wrote:
>>
>>> IMO, inout (and const/immutable to a degree) is a failure for use with
>>> class/struct methods. This became clear to me when trying to use it for
>>> the toString implementation of Nullable.
>>
>> You'd have to be more specific for me to understand your point. inout
>> was specifically designed for one-implementation accessors for members
>> of classes/structs.
>>
>> -Steve
>
> I cannot remember what the exact issue is now as it was awhile ago, but
> it had to do with a creating inout/const/immutable Nullables. When doing
> something such as `Nullable!TestStruct ts; writeln(ts)`, the check
> inside Nullable.get is triggered instead of calling toString, because
> toString is not marked as inout/const/immutable. The only solution seems
> to have a separate version of toString for inout, const, and immutable.
> It seems that pretty much defeats the point of having inout in the first
> place.

That sounds like the delegate issue. If you are not dealing with 
delegates, then it works well.

Working with inout delegates gets tricky, because it's impossible to 
refer to inout the type constructor as a parameter to a function without 
the compiler thinking this is a new invocation of inout.

Timon Gehr had ideas on how to fix it, but I don't think anything ever 
came of it.

-Steve