http://wiki.dlang.org/DIP25

[Steven Schveighoffer via Digitalmars-d]

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