<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 September 2014 23:38, Kagamin 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Monday, 22 September 2014 at 11:20:57 UTC, Manu via Digitalmars-d wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It is a useful tool, but you can see how going to great lengths to write<br>
this explosion of paths is a massive pain in the first place, let alone<br>
additional overhead to comprehensively test that it works... it should<br>
never have been a problem to start with.<br>
</blockquote>
<br></span>
Hmm... even if the code is syntactically succinct, it doesn't necessarily mean lower complexity or that it requires less testing. You provided an example yourself: you have generic code, which works for values, but not for references. You need a lot of testing not because the features have different syntax, but because they work differently, so code, which works for one thing, may not work for another.<br>
</blockquote></div><br></div><div class="gmail_extra">Eliminating static branches containing different code has a very significant reduction in complexity. It's also DRY.</div><div class="gmail_extra">I don't think I provided that example... although it's certainly true that there are semantic differences that may lead to distinct code paths, it is my experience that in the majority of cases, if I just had the ref-ness as part of the type, the rest would follow naturally. I have never encountered a situation where I would feel hindered by ref as part of the type.</div><div class="gmail_extra">I think it's also easier to get from ref in the type to the raw type than the reverse (which we must do now); We are perfectly happy with Unqual!T and things like that.</div></div>