'new' class method

[Benji Smith]

Bill Baxter wrote:
>> auto c = Class(...);   // default on heap
>> auto s = Struct(...);  // default on stack (compatible with current syntax)
>>
>> scope c = Class(...);  // on stack
>> scope s = Struct(...); // on stack (compatible with current syntax)
> 
> The main thing I don't like about this syntax is that it makes it
> impossible to create a class temporary on the stack in an expressoin.
> It means you always have to declare it and give it a name if you want
> to avoid the heap.  It's just not orthogonal in that way.  As in it
> entangles construction with declaration, when those two are usually
> separate concerns.

Agree with you 1000%.

This is one of my minor annoyances with D. Static arrays and structs 
must be constructed in a statement, rather than in an expression like 
everything else.

    MyStruct s; // why can't a MyStruct be created in an expression?
    float[3] f; // same deal here! what gives?

I'd very much like to see a little more unification in construction 
semantics, among classes, structs, and all the different types of arrays.

For one thing, if construction semantics was more unified, it'd be much 
more straightforward to "upgrade" certain bits of code if/when you 
decide to switch from a struct implementation to a class (or vice 
versa). It'd probably also be simpler to write certain kinds of 
templates (though no examples spring to mind right now).

Anyhow, If this business of getting rid of "new" is a step in that 
direction, I'm all for it.

>> /* if you want symmetry, do it like this:
>>
>> new c = Class(...);
>> new(...) c = Class(...);
>> kinda strange for me. */
> 
> Yeh, me too.  I definitely don't want any more of this sillyness of
> mixing up construction with declaration.

Ditto.

> Another possibility might be to introduce some syntax for heap vs
> stack and only use () for placement new -- like this:
> 
>      Class.*new(construct_args);   // stack (like *foo is dereferenced
> foo pointer)
>      Struct.*new(construct_args);  // stack
> 
>      Class.new(construct_args); // heap
>      Struct.new(construct_args); // heap
> 
>      Class.new@(new_args)(construct_args);  // placement
>      Struct.new@(new_args)(construct_args); // placement

Hmmmmmm. Nope.

I'll know it when I see it, but this is definitely not it :)

>>> For non-template chained calls, I'm not quite sure which I prefer:
>>>
>>>  auto a = Foo.new(heap)(Bar.new(stack)());
>>>
>>>  auto a = on(heap) Foo(on(stack) Bar());
> 
> I think Andrei is gunning to get rid of the dangling prefix words in
> the grammar.  That's why I put .new at the end.  I think he would also
> be happy with a regular function-like syntax, too, but what I've seen
> of that looks ugly.  When you do 'new' there always a class or struct
> involved, so why not make it a pseudo property of every class and
> struct, just like .init or .tupleof?

Maybe...

It still doesn't seem quite right, though.

Really, it's the GC that's doing the allocating, so the "new" function 
ought to belong to the GC object, and the constructor could be a 
delegate passed to the GC...

    auto x = GC.new(&Constructor);

I admit, I don't really like that either :o(

But at least it makes it a little clearer what's going on than the 
Foo.new()() syntax.

Back to the drawing board!!!

--benji