On Thu, Jan 24, 2019 at 1:25 AM Nicholas Wilson via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote: > > On Thursday, 24 January 2019 at 07:18:58 UTC, Mike Parker wrote: > > Walter and Andrei have declined to accept DIP 1016, "ref T > > accepts r-values", on the grounds that it has two fundamental > > flaws that would open holes in the language. They are not > > opposed to the feature in principle and suggested that a > > proposal that closes those holes and covers all the bases will > > have a higher chance of getting accepted. > > > > You can read a summary of the Formal Assessment at the bottom > > of the document: > > > > https://github.com/dlang/DIPs/blob/master/DIPs/rejected/DIP1016.md > > > void atomicIncrement(ref shared long x); > > atomicIncrement(myInt); > > Raises a good point, not covered by @disable where the intent is > to modify it and modifying a temporary is wrong. `out ref` > perhaps?
Actually, this was discussed, but somehow this piece of discussion didn't get folded back it to the DIP. It is mentioned in the 'Community Review Round 1' digest though. We discussed and concluded that one mechanism to mitigate this issue was already readily available, and it's just that 'out' gains a much greater sense of identity (which is actually a positive side-effect if you ask me!). You have a stronger motivation to use 'out' appropriately, because it can issue compile errors if you accidentally supply an rvalue. That doesn't address the specific `atomicIncrement` case here, but now we're in VERY niche territory; we analysed a lot of cases, and concluded that such cases were relatively few, and other choices exist to mitigate those cases. There are cases that want to do mutation to rvalues (like in pipeline functions), and then most cases can use 'out' instead. Remaining cases are quite hard to find, and in this particular case, I'd suggest that `atomicIncrement`, a very low-level implementation-detail function, should just receive a pointer.