<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr">On Sat., 21 Jul. 2018, 12:30 pm Johnatune via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was for this back when it was only for 'const ref' but that <br>
somehow changed to just ref. Which I think is a mistake. Yes D's <br>
const is broken and useless, but I don't think that's a reason to <br>
introduce difficult to locate bugs with the addition of this <br>
feature. There's not a simple way to locate where code might be <br>
breaking if a temporary value is being passed to a ref function <br>
when it wasn't intended. Right now this is a compiler error, even <br>
in C++. But with this proposed change it might take a lengthy <br>
amount of time in the debugger trying to understand what is <br>
happening.<br>
<br>
Yes I want rvalue refs, just not like this.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It's like you didn't read the DIP.</div><div dir="auto"><br></div><div dir="auto">I was initially very hesitant as you, but I was motivated to remove the const restriction when I realised that usefulness of the pattern far exceeds what you're familiar with in C++.</div><div>While interacting with interfaces similar to C++ is one motivating use case (particularly for myself), I realised that pipeline programming and 'return ref' change the game.</div><div>They are distinctly "D" coding styles, and this issue is a cause of friction with respect to one of D's greatest success stories.</div><div>Such use with pipelines and 'return ref' imply that mutable ref also supported.</div><div><br></div><div>There is indeed also the restrictive-const issue, and the current recommendation is to not over-use const. >From that perspecetive, this DIP is in-line with current recommendations regarding const; it is obviously naturally supported, but not mandated.<br></div><div><br></div><div>Finally, I have really thought about the problem case that everyone is so terrified about, and I am still trying to visualise real-world situations where that could arise. Please read the replies to Jonathan's sub-thread... that has all the detail on that.</div><div><br></div><div>TLDR:</div><div>  - The fear in question relates to a general class of problem and not specifically related to 'ref' - that's just one of very many ways to expose the 'accidentally modified an rvalue' issue.</div><div>  - I don't believe it's within 'ref's responsibility domain to fight that class of problem, particularly at the expense of the other advantages we're inhibiting (proposed in thie DIP).</div><div>  - We're still trying to identify probably real-world examples.</div><div>  - Your fear is mostly invalid. And even if it's not, the DIP proposes a very nice and principled mechanism to retain "lval-only please" API design.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
</div>