<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 September 2014 01:10, Andrei Alexandrescu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 9/21/14, 4:27 AM, Manu via Digitalmars-d wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
On 21 September 2014 16:02, deadalnix via Digitalmars-d<br></span><span class="">
<<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a> <mailto:<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@<u></u>puremagic.com</a>>> wrote:<br>
<br>
On Sunday, 21 September 2014 at 03:48:36 UTC, Walter Bright wrote:<br>
<br>
On 9/12/2014 6:48 PM, Manu via Digitalmars-d wrote:<br>
<br>
What happens when a scope() thing finds it's way into<br>
generic code? If the type<br>
doesn't carry that information, then you end up in a<br></span>
situation like ref.. Have<span class=""><br>
you ever had to wrestle with ref in generic code?<br>
ref is the biggest disaster zone in D, and I think all it's<br>
problems will<br>
translate straight to scope if you do this.<br>
<br>
<br>
I'm unaware of this disaster zone.<br>
<br>
<br>
Well it is very real. I had to duplicate bunch of code in my visitor<br>
generator recently because of it. Getting generic code ref correct<br>
is very tedious, error prone, and guarantees code duplication and/or<br>
various static ifs all over the place.<br>
<br>
<br></span><span class="">
It's also extremely hard to unittest; explodes the number of static if<br></span>
paths exponentially.. I'm constantly finding bugs appear a year after<span class=""><br>
writing some code because I missed some static branch paths when<br>
originally authoring.<br>
</span></blockquote>
<br>
Is this because of problems with ref's definition, or a natural consequence of supporting ref parameters? -- Andrei<br>
</blockquote></div><br></div><div class="gmail_extra">It's all because ref is not part of the type.</div><div class="gmail_extra">You can't capture ref with typeof() or templates, you can't make ref locals, it's hard to find if something is ref or not (detection is different than everything else), etc.</div><div class="gmail_extra">The nature of it not being a type leads to static if's in every template that ref appears, which must detect if things are ref (which is awkward), and produce multiple paths for a ref and not-ref version. If we're dealing with arguments, this might lead to num-arguments^^2 paths.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The only practical conclusion I (and others too) have reached, is to eventually give up and invent Ref!T, but then we arrive at a new world of problems. It's surprisingly hard to write a transparent Ref template which interacts effectively with other generic code, and no 3rd party library will support it.</div></div>