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.
