Copy constructors for lazy initialization

[Steven Schveighoffer]

On Fri, 28 May 2010 21:26:50 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Walter has had a great idea last night: allow classes to define

I'm almost positive you meant "allow *structs* to define"

>
> this(ref S src);
>
> where S is the name of the struct being defined, as an alternative for
>
> this(this);
>

[snip]

> The idea of the copy constructor is to lazy initialize the source and  
> the target if the source has null state. That would take care of this  
> problem and the similar problems for shared state.
>
> There is still a possibility to call a method against an object with  
> null state. I think that's acceptable, particularly because lazy  
> initialization saves some state allocation.
>
> What do you think?

It is a good effort to solve the problem.  The problem I see with such  
constructs is inherently the lazy construction.  Because you must lazily  
construct such a container, every method meant to be called on the struct  
must first check and initialize the container if not done already.  This  
results in an undue burden on the struct author to make sure he covers  
every method.  The first method he forgets to lazily initialize the struct  
results in an obscure bug.

I wonder, would it be possible to go even further?  For example, something  
like this:

struct S
{
   lazy this()
   {
      // create state
   }
}

which would be called if the struct still has not been initialized?  lazy  
this() should be prepared to accept an already initialized struct, which  
should be no problem because most lazily initialized structs always differ  
 from the .init value.

The compiler could optimize this call out when it can statically determine  
that a struct has already been initialized.

This of course, does not cover copy construction, but it would be called  
before the copy constructor.

BTW, I'm glad you guys are looking at this problem.

-Steve