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

[Jonathan M Davis]

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