http://wiki.dlang.org/DIP25

[Manu via Digitalmars-d]

On 28 December 2014 at 13:09, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Walter and I have been working on revamping DIP25, which focuses on
> tightening the screws of ref. This should then simplify DIP69 significantly.
>
> Please comment: http://wiki.dlang.org/DIP25
>
>
> Thanks,
>
> Andrei

I could generally understand the intent, but I don't really understand
the connection between ref and inout.
They seem like unrelated things. I feel like conflating them could
only lead to unexpected problem cases when the concepts coincide
naturally, but the intent wasn't this assigned special case.
I wonder if we're just narrowing the window of edge cases, and
possibly into a slightly more awkward position for later fixes?

I'd like to see 'ref inout(int)' rather than 'ref inout int', to make
inout look like the type modifier that it is, rather than a storage
class, which it isn't.
That distinction made me start second-guessing my assumptions
throughout, and reduced my confidence in my understanding of the
proposal.

I'd also like to know how this will help DIP69? I can't imagine how
this could help DIP69 address the basic problems I was concerned with
(ie, distilling towards; 'storage class' is practically a bad design
for D, and my numerous rants and walls of text that follow).