On Thursday, November 15, 2012 19:30:03 Dan wrote: > On Thursday, 15 November 2012 at 17:24:44 UTC, Jonathan M Davis > > wrote: > > On Thursday, November 15, 2012 14:21:41 Dan wrote: > >> I do not see how copy constructors can help. Receiving const(T) > >> or const(T) ref to anything and hoping to copy it is the > >> challenge and doing it from a copy constructor is no easier > >> than > >> a postblit. > > > > Doing it from a postblit is impossible. > > I understand and this makes sense. postblit is not a deep copy, > it is only what you choose to make it.
The entire reason that postblit exists is to allow deep copies, just like with a copy constructor. You can certainly create a type which doesn't do a deep copy in its postblit constructor, but the reason that it's in the language is to make it so that you can do a deep copy of member variables which normally would end up being shallowly copied. It's D's attempt at making a better copy constructor. Pure and simple. But because of issues with const, it fails at that. > The problem for this case is it can > not guarantee what I do *in* my postblit and therefore it does > not and can not know I'm leaving with no sharing. The main problem is that once you're inside the postblit construct, the new object has already been fully constructed. And since it's illegal to cast away const and modify an object, it is therefore impossible to modify the new object inside the postblit constructor, making the postblit constructor utterly pointless and making it impossible to copy that struct through any standard means. You could create your own dup method, but that doesn't help one iota with all of the places in the language where you need the language to be making copies for you (e.g. when you dup an array of that struct type). Creating a non-const copy of a const object doesn't work either, but you're totally screwed if you can't even make a deep copy of const copy of a const object. Copy constructors would solve both problems. > The suggestion is use > copy constructors instead. I don't see how this will helpx A copy constructor will help, because it will make it possible to copy const objects which have member variables which are reference types and have a deep copy made because you'll be constructing the new object directly rather than copying it and then making changes to it. Right now, all you can get is a shallow copy, because postblit doesn't work with const. > but I > have not found the proposal (do you have a link?). I have read > DIP10 which was an early attempt to get at this stuff - but I > think it did not go far. There is no DIP for it. Andrei and Walter have discussed it in private, and all they would say for a while was that they had a solution. They wouldn't give what it was. Andrei did finally mention not too long ago that it involved introducing copy constructors and phasing out postblit constructors. But nothing has happened yet, and it has not yet been discussed in detail in the newsgroup, so what exactly is involved beyond the fact that they intend to introduce copy constructors to solve the problem, I don't know. > The only problem is > copy construction (and therefore postblit) is not the right tool > to copy const instances with reference semantics. That's a separate issue from the fact that const postblits don't work. If you've given a type reference semantics, then obviously copy constructors and postblits aren't going to do deep copies. For that, you'd probably create a dup function. But many, many types need to be able to be copied as value types even though they have member variables which are reference types - which is what copy constructors and postblit constructors are for - and they can't do that in D right if they're const, because const and postblit don't mix. - Jonathan M Davis