On Sun, 11 May 2014 17:00:13 +0000 > Remind me again why we can't just change this to a sensible > initial state? Or at least add a .initialize()?
All reference types have a null init value. Arrays and classes have the exact same issue as AAs. Anything else would require not only allocating memory but would require that that state persist from compile time to runtime, because the init value must be known at compile time, and there are many cases, where a variable exists at compile time (e.g. a module-level or static variable), making delayed initialization problematic. Previously, it was impossible to allocate anything other than arrays at compile time and have it's state persist through to runtime, though it's not possible to do that with classes (I don't know about AAs). So, it _might_ now be possible to make it so that AAs had an init value other than null, but because there's only one init value per type, even if the init value for AAs wasn't null, it wouldn't solve the problem. It would just result in all AAs of the same type sharing the same value unless they were directly initialized rather than having their init value used. Essentially, the way that default-initialization works in D makes it so that a default-initialized AA can't be its own value like you're looking for. For that, we'd need default construction (like C++ has), but then we'd lose out on the benefits of having a known init value for all types and would have the problems that that was meant to solve. It causes us problems with structs too for similar reasons (the lack of default construction there also gets complained about fairly frequently). Ultimately, it's a set of tradeoffs, and you're running into the negative side of this particular one. - Jonathan M Davis
