On 22 September 2014 23:38, Kagamin via Digitalmars-d < [email protected]> wrote:
> On Monday, 22 September 2014 at 11:20:57 UTC, Manu via Digitalmars-d wrote: > >> It is a useful tool, but you can see how going to great lengths to write >> this explosion of paths is a massive pain in the first place, let alone >> additional overhead to comprehensively test that it works... it should >> never have been a problem to start with. >> > > 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. > Eliminating static branches containing different code has a very significant reduction in complexity. It's also DRY. 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. 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.
