http://wiki.dlang.org/DIP25

[Meta via Digitalmars-d]

On Monday, 5 January 2015 at 14:00:13 UTC, Steven Schveighoffer 
wrote:
> On 1/5/15 8:06 AM, deadalnix wrote:
>> On Monday, 29 December 2014 at 20:26:27 UTC, Steven 
>> Schveighoffer wrote:
>>> On 12/29/14 2:50 PM, Walter Bright wrote:
>>>> On 12/29/2014 5:53 AM, Steven Schveighoffer wrote:
>>>>> On 12/28/14 4:33 PM, Walter Bright wrote:
>>>>>> inout is not transitive, so a ref on the container doesn't 
>>>>>> apply to a
>>>>>> ref on the contents if there's another level of 
>>>>>> indirection in there.
>>>>> I'm not sure what you mean by this, but inout as a type 
>>>>> modifier is
>>>>> definitely
>>>>> transitive.
>>>>
>>>> As a type modifier, yes, it is transitive. As transferring 
>>>> lifetime to
>>>> the return value, it is not.
>>>>
>>>
>>> I strongly suggest not to use inout to mean this. This idea 
>>> would be a
>>> disaster.
>>
>> On the other hand, inout IS a disaster, so why not ?
>
> I strongly disagree :) inout enables so many things that just 
> aren't possible otherwise.
>
> Most recent example: 
> https://github.com/D-Programming-Language/druntime/pull/1079
>
> inout only gets confusing when you start using inout delegates.
>
> -Steve

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.