On 28 December 2014 at 13:09, Andrei Alexandrescu via Digitalmars-d <[email protected]> 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).
