Time to kill T() as (sometimes) working T.init alias ?

[Dan]

On Tuesday, 11 December 2012 at 07:19:07 UTC, monarch_dodra wrote:
> Here is a example of using COW for a simple object that wraps
> nothing more than an int:
>
[snip]
> This means you only pay for the copy when you *actually* need 
> it.
>
> Drawbaks from this approach include:
> 1. Needs actual code.
> 2. NOT actually cheap: The counter goes up, and down, on each 
> and
> every copy/destruction/pass: Requires a destructor and a 
> postblit
> for RAII.
> 3 Implements deep ownership (*)
>
> *Imo, this is the worst part of COW for a language like D. In
> theory, you could just allocate your payload, and let the GC and
> default copy take care of everything else, and move on with your
> life. COW is (IMO) a c++ relic. Not only is this approach easy,
> but it is *also* efficient. If you *do* need actual object
> duplication, then you can implement "dup".
>

Thank you for the example. I see the benefit if performance is an 
issue ... but what happened to premature optimization? For 
example, the difference between the simple code below and a 
version with COW may be easy - but I don't think it is trivial. 
There is a fair amount of boilerplate bookeeping. What if the 
struct had two, three, or more maps: V1[K1], V2[K2], V3[K3]. 
Would you have three separate reference counter payloads, or just 
one payload with three maps? If you choose the latter you are 
still aggressively copying when unnecessary. It seems one could 
quickly take this to extremes. I did not understand the part 
about "In theory, you could just allocate your payload, and let 
the GC and default copy take care of everything else".

---
struct AddressBook {
   alias Address[string] EmailAddressMap;
   this(this) { _emailAddressMap = _emailAddressMap.dup; }
   void addAddress(string email, Address address) {
     _emailAddressMap[email] = address;
   }
   private EmailAddressMap _emailAddressMap;
}
---


> //---------------------------------------
> BTW: There is a subtle bug in this code. Can you spot it ;) ?

For me it did not compile (No constructor for payload), maybe you 
had a ctor for Payload? I think opAssign is not necessary - if I 
remove it it still seems to work since default opAssign calls 
postblit. I added the ctor, removed opAssign and put it here: 
http://dpaste.dzfl.pl/6ecfe675

Other than that - is there still a subtle bug?

Thanks,
Dan