Time to kill T() as (sometimes) working T.init alias ?
Jonathan M Davis
jmdavisProg at gmx.com
Sun Dec 9 13:41:46 PST 2012
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
More information about the Digitalmars-d
mailing list