funky property error with assoc array

[Jonathan M Davis]

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