On 22 September 2014 23:38, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> 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.