On Sunday, December 09, 2012 13:11:43 Walter Bright wrote: > On 12/9/2012 11:16 AM, Jonathan M Davis wrote: > > That's kind of the point of having posblits in the first place, > > As I argued previously, the only justification I can think of for postblit > is for reference counting. The counters posted here were variations on > reference counting, or could be done in terms of reference counting. > > In fact, I think we could solve the postblit problems with const, immutable, > and shared by dispensing with postblit entirely and providing some sort of > compiler magic for doing ref counting.
It is incredibly common in C++ to have objects which live on the stack and are deep-copied when they're copied. postblit allows us to do the same in D (aside from the issues with it not working with const and immutable), and TDPL even gives examples of doing precisely that (e.g. duping an array in a postblit constructor). I don't see why we should disallow structs which are deep copied when they're copied. You're then forcing everything which contains any kind of reference types to be a reference type. And if you're going to do that, why not just make them all classes? Why allow complex structs like we have if you're just going to hamstring them like that? We could have just gone with C#'s limited structs if that's what you're looking for. Declaring a struct which contains reference types and does a deep copy with postblit obviously incurs a performance cost, but it's up to the programmer who declared it to decide whether that's worth it or not. I see no reason for the language to try and disallow that. That's overly restrictive. - Jonathan M Davis