'new' class method

[Sergey Gromov]

Fri, 24 Oct 2008 14:32:23 +0800,
KennyTM~ wrote:
> Bill Baxter wrote:
> > On Fri, Oct 24, 2008 at 6:28 AM, Sergey Gromov <snake.scaly at gmail.com> wrote:
> >> Fri, 24 Oct 2008 05:31:44 +0900,
> >> Bill Baxter wrote:
> >>> But, ok, this isn't Python so we have to have a story for placement new.
> >>> I believe use of placement new is pretty rare.  (I use it rarely,
> >>> anyway. :-) )   If so it should be ok if the syntax is a little
> >>> clunky.
> >> Maybe do it with a library function?
> >>
> >> auto c = core.intrinsic.construct!(C)(addr, ctor_arg0, ctor_arg1);
> > 
> > The current placement new in D can take an arbitrary list of args.  So
> > you have two lists -- new_args and ctor_args.
> > 
> > --bb
> 
> Can a library function return a constructor? Like this:
> 
> auto c = core.intrinsic.construct!(C)(addr, new_args...)(ctor_args ...);
> 
> But that's similar to C.new(addr, new_args...)(ctor_args...);

It shouldn't be easy to call a constructor directly--you don't want to do 
it by accident.

Current new semantics automates and hides a lot of stuff under the hood:

* calculates the required size
* calls an allocator of the class to be constructed, choosing the 
allocator according to overloading rules
* calls a constructor for the same class, choosing the constructor 
according to overloading rules
* converts the results into a class reference

In theory, if you drop part of this automation, it's sufficient to have a 
built-in function that calls a constructor on an arbitrary memory and 
returns a reference to the constructed object.