On 12/29/14 2:57 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:54:33 UTC, Steven Schveighoffer wrote:
On 12/29/14 2:04 PM, Dicebot wrote:
On Monday, 29 December 2014 at 19:00:06 UTC, Andrei Alexandrescu wrote:
I tend to agree. You seem to have shown that reusing inout for scope
information becomes confusing. -- Andrei
What is the problem with using inout exactly as it is now (== both for
argument and return type) but defining it to propagate aliasing
information as it is decribed in DIP25?
It can, and I don't have a problem for that.
But I think disallowing:
ref T foo(T)(ref T t) { return t;}
Is no good.
It is to be disallowed only in @safe code, right?
Even in safe code, if it's safe to do so, it should be allowed.
I think the driving point behind this push is that when you see:
ref T foo(ref T t);
how do you know if the return of foo is somehow related to t or not? The
DIP is saying if you return something related to t, you have to mark t
as inout. At least, this is my understanding. But this precludes doing
anything with a mutable t inside foo, since inout means "const within
the function".
The DIP seems to be indicating inout can have another use that has
nothing to do with const, but I'm not exactly sure.
I see its potential as a generic wildcard for attribute/qualifier
propagation through the functions.
It's not generic at all. It's a concrete type qualifier that does not
generate a template. When inside an 'inout' function, anything marked as
inout is transitively const.
-Steve
