On 23 September 2014 19:45, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > > On 9/22/2014 4:20 AM, Manu via Digitalmars-d wrote: >> >> On 22 September 2014 13:19, Walter Bright via Digitalmars-d >> <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: >> >> On 9/21/2014 4:27 AM, Manu via Digitalmars-d wrote: >> >> It's also extremely hard to unittest; explodes the number of static >> if paths >> exponentially. I'm constantly finding bugs appear a year after >> writing >> some code >> because I missed some static branch paths when originally authoring. >> >> >> If you throw -cov while running unittests, it'll give you a report on >> which >> code was executed and which wasn't. Very simple and useful. >> >> >> 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. > > > There are two separate issues here - the first is knowing whether or not the > code is unittested. -cov solves that issue. The second is having the multiple > code paths in the first place. > > Have you tried auto ref?
auto ref has never been what I've wanted. Semantically, it makes ref out of all value-type lvalues, including int/float. I don't want the compiler attempting to presume what I want in my generic code. If it's part of the type, then there are no surprises; it is exactly what I give it, which I gave deliberately. > I don't really know what the code you show is supposed to do from a high > level. My first impression is you are trying to write it like you'd write C++ > code. Perhaps there's a more D idiomatic way of doing it that doesn't lead to > the tangle you've got. The only way I can think to eliminate that is to write the lot in a huge mixin which composes the text from bits. I avoid mixin. D has extensive language to manipulate and compare types, it has very little to deal with these few weird external concepts like 'storage class'. D has the most powerful type system I'm aware of, I see no reason to break from that. I think 'storage class' is a source of extreme complexity in D, since it breaks uniformity with the rest of the language. > BTW, ref (as you know) is part of the type in C++. However, I can vouch for > it being a special case everywhere in C++, and is a horrifying quagmire of > strange edge cases. That's why it's not part of the type in D. I've never had any problems with ref in C++. D presents the horrible quagmire of edge cases in my experience, some of which I've presented, but I've had many more issues in the past. Can you give me some examples of the problems in C++ you set out to avoid? I've been programming C++ for 20 years, and D for 5-6 years. I've never had this problem in C++, I have it so often in D, it drives me crazy. I also believe that D wouldn't suffer the same problems as C++, because we have much better type manipulation. Things like PointerTarget!T, Unqual!T, and all the other complex type manipulation templates are common and work well in D, but that sort of thing almost never works well in C++. The type comparison logic in C++ is too feeble to be comparably useful.