== Quote from Don ([email protected])'s article > Now that we have struct literals, the old C-style struct initializers > don't seem to be necessary. > The variations with named initializers are not really implemented -- the > example in the spec doesn't work, and most uses of them cause compiler > segfaults or wrong code generation. EG... > struct Move{ > int D; > } > enum Move genMove = { D:4 }; > immutable Move b = genMove; > It's not difficult to fix these compiler problems, but I'm just not sure > if it's worth implementing. Maybe they should just be dropped? (The { > field: value } style anyway).
I'd be inclined to say go for it, because it's yet another crufty feature inherited from C that I don't use, was barely aware even existed, and has been superseded by a better feature that's unique to D. What can be done with struct initializers that can't be done just as easily with struct literals? As far as I can tell (correct me if I'm wrong), nothing. IMHO we concern ourselves with C source compatibility and ease of porting C code too much sometimes. If people want a language that's source compatible with C, they want C++ and they know where to find it. If they want a language that sacrifices backwards compatibility to get rid of tons of cruft, then that's what D is and we shouldn't be ashamed of it. If we kinda sorta care about C source compatibility, we won't attract either audience.
