Fri, 20 Nov 2009 05:59:21 +0000, dsimcha wrote: > == 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.
Well said.
