Walter Bright Wrote: > D aims to reduce project costs by reducing training time and shortening > development time.
It really hasn't worked out that way for me with D2. Here's an example from yesterday: I picked up where I left off with creating a weak ref library, something most other GC'd languages have as part of their standard library. It probably comes as no surprise that I was getting seg faults. Of course, those are supposed to be trivial to solve. I run the app through gdb, and catch the crash. I can see the stack but can't figure out which line the fault occurred on or what the important local variables are set to. I make up an incorrect theory of what could be going on and start a detailed sifting through all actions of the gc. Everything was fine :( I somehow notice later in the night a small usage difference between my code and the GC. I fix that and try a better test to ensure things work. I see previously working code is now broken. I start checking code and settle on std.conv being broken. Out of the 15 candidates for to!(T), I overlook the one that should be used, but do spot what is incorrectly being used. The code looks legit - do a conversion to a string from a struct, but only if it lacks a toString function. I have a to string function! I test the logic with a static assert and it's wrong. Is this a compiler bug? I remember some screwy is expression syntax and try that instead. Looks like the screwy syntax is needed. I have always hated the is syntax because it's non-intuitive. It looks like Mr. Metaprogramming (Andrei) got it wrong.
