www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 'new' class method

reply bearophile <bearophileHUGS lycos.com> writes:
In Python to create new instances of a class you use the normal function call
syntax, this allows you to use them as factory functions:

class C:
    def __init__(self, id):
        self.id = id
    def __repr__(self):
        return "<%s>" % self.id
seq = map(C, [1, -5, 10, 3])

That creates an array (list) of four objects.

In D with a map() you can do something similar:

import d.all;
import std.string: format;

class C {
    int id;
    this(int id) {
        this.id = id;
    }
    string toString() {
        return format("<%s>", this.id);
    }
    static C opCall(int id) {
        return new C(id);
    }
}
void main() {
    auto seq = map((int id){return new C(id);}, [1, -5, 10, 3]);
    putr(seq);
}

You can use the opCall method in a more direct way:

    auto seq2 = map(&(C.opCall), [1, -5, 10, 3]);
    putr(seq2);

But probably even better is to replace the current new syntax with a class
method that creates the instances (I think the Ruby language has such syntax):

    auto seq3 = map(C.new, [1, -5, 10, 3]);
    putr(seq3);

With that normal code like:

new Foo(10, 20)

becomes:

Foo.new(10, 20)

Not a big change but allows a more functional style of coding.

Bye,
bearophile
Oct 23 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 23, 2008 at 6:32 PM, bearophile <bearophileHUGS lycos.com> wrote:

 In Python to create new instances of a class you use the normal function call
syntax, this allows you to use them as factory functions:

 class C:
    def __init__(self, id):
        self.id = id
    def __repr__(self):
        return "<%s>" % self.id
 seq = map(C, [1, -5, 10, 3])

 That creates an array (list) of four objects.

 In D with a map() you can do something similar:

 import d.all;
 import std.string: format;

 class C {
    int id;
    this(int id) {
        this.id = id;
    }
    string toString() {
        return format("<%s>", this.id);
    }
    static C opCall(int id) {
        return new C(id);
    }
 }
 void main() {
    auto seq = map((int id){return new C(id);}, [1, -5, 10, 3]);
    putr(seq);
 }

 You can use the opCall method in a more direct way:

    auto seq2 = map(&(C.opCall), [1, -5, 10, 3]);
    putr(seq2);

 But probably even better is to replace the current new syntax with a class
method that creates the instances (I think the Ruby language has such syntax):

    auto seq3 = map(C.new, [1, -5, 10, 3]);
    putr(seq3);


That would be  map(&(C.new), [1,-5,10,3]); wouldn't it?


 With that normal code like:

 new Foo(10, 20)

 becomes:

 Foo.new(10, 20)

 Not a big change but allows a more functional style of coding.


I like it.   Can we get rid of delete's specialness too?

Maybe just    delete(anInstance);
Make it like a normal function too.   Enabling things like

   map(&delete, [obj1, obj2, obj3])

--bb
Oct 23 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Bill Baxter wrote:

 On Thu, Oct 23, 2008 at 6:32 PM, bearophile
 <bearophileHUGS lycos.com> wrote:

 In Python to create new instances of a class you use the normal
 function call syntax, this allows you to use them as factory
 functions:
 
 class C: def __init__(self, id): self.id = id def __repr__(self): 
 return "<%s>" % self.id seq = map(C, [1, -5, 10, 3])
 
 That creates an array (list) of four objects.
 
 In D with a map() you can do something similar:
 
 import d.all; import std.string: format;
 
 class C { int id; this(int id) { this.id = id; } string toString()
 { return format("<%s>", this.id); } static C opCall(int id) { 
 return new C(id); } } void main() { auto seq = map((int id){return
 new C(id);}, [1, -5, 10, 3]); putr(seq); }
 
 You can use the opCall method in a more direct way:
 
 auto seq2 = map(&(C.opCall), [1, -5, 10, 3]); putr(seq2);
 
 But probably even better is to replace the current new syntax with
 a class method that creates the instances (I think the Ruby
 language has such syntax):
 
 auto seq3 = map(C.new, [1, -5, 10, 3]); putr(seq3);


 
 That would be  map(&(C.new), [1,-5,10,3]); wouldn't it?
 

 With that normal code like:
 
 new Foo(10, 20)
 
 becomes:
 
 Foo.new(10, 20)
 
 Not a big change but allows a more functional style of coding.


 
 I like it.   Can we get rid of delete's specialness too?
 
 Maybe just    delete(anInstance); Make it like a normal function too.
 Enabling things like
 
 map(&delete, [obj1, obj2, obj3])
 
 --bb


Andrei already mentioned that he wants to get read of new/delete IIRC.
I like Ruby's way of making it regular methods. something like:
obj.new(..) and obj.delete()
but, how do you specify stack vs heap allocation?
something like:
auto a = new S(); //on heap
auto b = S(); //on stack

also, what about placement new?
Oct 23 2008
next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 23, 2008 at 8:47 PM, Yigal Chripun <yigal100 gmail.com> wrote:

 Bill Baxter wrote:

 On Thu, Oct 23, 2008 at 6:32 PM, bearophile
 <bearophileHUGS lycos.com> wrote:

 In Python to create new instances of a class you use the normal
 function call syntax, this allows you to use them as factory
 functions:

 class C: def __init__(self, id): self.id = id def __repr__(self):
 return "<%s>" % self.id seq = map(C, [1, -5, 10, 3])

 That creates an array (list) of four objects.

 In D with a map() you can do something similar:

 import d.all; import std.string: format;

 class C { int id; this(int id) { this.id = id; } string toString()
 { return format("<%s>", this.id); } static C opCall(int id) {
 return new C(id); } } void main() { auto seq = map((int id){return
 new C(id);}, [1, -5, 10, 3]); putr(seq); }

 You can use the opCall method in a more direct way:

 auto seq2 = map(&(C.opCall), [1, -5, 10, 3]); putr(seq2);

 But probably even better is to replace the current new syntax with
 a class method that creates the instances (I think the Ruby
 language has such syntax):

 auto seq3 = map(C.new, [1, -5, 10, 3]); putr(seq3);


 That would be  map(&(C.new), [1,-5,10,3]); wouldn't it?


 With that normal code like:

 new Foo(10, 20)

 becomes:

 Foo.new(10, 20)

 Not a big change but allows a more functional style of coding.


 I like it.   Can we get rid of delete's specialness too?

 Maybe just    delete(anInstance); Make it like a normal function too.
 Enabling things like

 map(&delete, [obj1, obj2, obj3])

 --bb


 Andrei already mentioned that he wants to get read of new/delete IIRC.
 I like Ruby's way of making it regular methods. something like:
 obj.new(..) and obj.delete()
 but, how do you specify stack vs heap allocation?
 something like:
 auto a = new S(); //on heap
 auto b = S(); //on stack

 also, what about placement new?


Hmm, I didn't realize D had a placement new.  But clearly it does and
more -- you can pass args to new to control the allocator.
  http://www.digitalmars.com/d/2.0/class.html
  look for "Class Allocators".
also
  http://www.digitalmars.com/d/2.0/memory.html#newdelete

So simply saying make it Obj.new(args) won't cut it.  You need to be
able to do something like
    Obj.new(newargs)(constructorargs)
also.

--bb
Oct 23 2008
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Yigal Chripun (yigal100 gmail.com)'s article

 Bill Baxter wrote:

 On Thu, Oct 23, 2008 at 6:32 PM, bearophile
 <bearophileHUGS lycos.com> wrote:

 In Python to create new instances of a class you use the normal
 function call syntax, this allows you to use them as factory
 functions:

 class C: def __init__(self, id): self.id = id def __repr__(self):
 return "<%s>" % self.id seq = map(C, [1, -5, 10, 3])

 That creates an array (list) of four objects.

 In D with a map() you can do something similar:

 import d.all; import std.string: format;

 class C { int id; this(int id) { this.id = id; } string toString()
 { return format("<%s>", this.id); } static C opCall(int id) {
 return new C(id); } } void main() { auto seq = map((int id){return
 new C(id);}, [1, -5, 10, 3]); putr(seq); }

 You can use the opCall method in a more direct way:

 auto seq2 = map(&(C.opCall), [1, -5, 10, 3]); putr(seq2);

 But probably even better is to replace the current new syntax with
 a class method that creates the instances (I think the Ruby
 language has such syntax):

 auto seq3 = map(C.new, [1, -5, 10, 3]); putr(seq3);


 That would be  map(&(C.new), [1,-5,10,3]); wouldn't it?


 With that normal code like:

 new Foo(10, 20)

 becomes:

 Foo.new(10, 20)

 Not a big change but allows a more functional style of coding.


 I like it.   Can we get rid of delete's specialness too?

 Maybe just    delete(anInstance); Make it like a normal function too.
 Enabling things like

 map(&delete, [obj1, obj2, obj3])

 --bb


 Andrei already mentioned that he wants to get read of new/delete IIRC.
 I like Ruby's way of making it regular methods. something like:
 obj.new(..) and obj.delete()
 but, how do you specify stack vs heap allocation?
 something like:
 auto a = new S(); //on heap
 auto b = S(); //on stack
 also, what about placement new?


One thing I would definitely like to see is for struct and class syntax to be
unified so that if you change a struct to a class or vice versa, this doesn't
require changes all over your code.  Then again, the reference vs. value
semantic
issue may bite you anyhow.
Oct 23 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 23, 2008 at 9:26 PM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Yigal Chripun (yigal100 gmail.com)'s article

 Bill Baxter wrote:

 On Thu, Oct 23, 2008 at 6:32 PM, bearophile
 <bearophileHUGS lycos.com> wrote:

 In Python to create new instances of a class you use the normal
 function call syntax, this allows you to use them as factory
 functions:

 class C: def __init__(self, id): self.id = id def __repr__(self):
 return "<%s>" % self.id seq = map(C, [1, -5, 10, 3])

 That creates an array (list) of four objects.

 In D with a map() you can do something similar:

 import d.all; import std.string: format;

 class C { int id; this(int id) { this.id = id; } string toString()
 { return format("<%s>", this.id); } static C opCall(int id) {
 return new C(id); } } void main() { auto seq = map((int id){return
 new C(id);}, [1, -5, 10, 3]); putr(seq); }

 You can use the opCall method in a more direct way:

 auto seq2 = map(&(C.opCall), [1, -5, 10, 3]); putr(seq2);

 But probably even better is to replace the current new syntax with
 a class method that creates the instances (I think the Ruby
 language has such syntax):

 auto seq3 = map(C.new, [1, -5, 10, 3]); putr(seq3);


 That would be  map(&(C.new), [1,-5,10,3]); wouldn't it?


 With that normal code like:

 new Foo(10, 20)

 becomes:

 Foo.new(10, 20)

 Not a big change but allows a more functional style of coding.


 I like it.   Can we get rid of delete's specialness too?

 Maybe just    delete(anInstance); Make it like a normal function too.
 Enabling things like

 map(&delete, [obj1, obj2, obj3])

 --bb


 Andrei already mentioned that he wants to get read of new/delete IIRC.
 I like Ruby's way of making it regular methods. something like:
 obj.new(..) and obj.delete()
 but, how do you specify stack vs heap allocation?
 something like:
 auto a = new S(); //on heap
 auto b = S(); //on stack
 also, what about placement new?


 One thing I would definitely like to see is for struct and class syntax to be
 unified so that if you change a struct to a class or vice versa, this doesn't
 require changes all over your code.  Then again, the reference vs. value
semantic
 issue may bite you anyhow.


To me this makes a lot of sense:

auto a = SomeStruct();  // a is a struct on the stack
auto b = SomeClass();  // b is a class on the heap

It kills static opCall for classes, but who cares.  I'm often tempted
to write static opCalls for classes like this anyway:
    static SomeClass opCall() {  return new SomeClass(); }

Just to get the uniformity of construction syntax.


--bb
Oct 23 2008
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Bill Baxter" wrote

 To me this makes a lot of sense:

 auto a = SomeStruct();  // a is a struct on the stack
 auto b = SomeClass();  // b is a class on the heap

 It kills static opCall for classes, but who cares.  I'm often tempted
 to write static opCalls for classes like this anyway:
    static SomeClass opCall() {  return new SomeClass(); }

 Just to get the uniformity of construction syntax.


It also cleans up this ugliness:

auto data = (new FileInput(filename)).readAll();

Which then becomes:

auto data = FileInput(filename).readAll();

-Steve
Oct 23 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 24, 2008 at 5:07 AM, Steven Schveighoffer
<schveiguy yahoo.com> wrote:

 "Bill Baxter" wrote

 To me this makes a lot of sense:

 auto a = SomeStruct();  // a is a struct on the stack
 auto b = SomeClass();  // b is a class on the heap

 It kills static opCall for classes, but who cares.  I'm often tempted
 to write static opCalls for classes like this anyway:
    static SomeClass opCall() {  return new SomeClass(); }

 Just to get the uniformity of construction syntax.


 It also cleans up this ugliness:

 auto data = (new FileInput(filename)).readAll();

 Which then becomes:

 auto data = FileInput(filename).readAll();


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.

Also heap construction of structs.

How about this as a start:

// Default cases
auto a = SomeStruct(arg);  // struct on the stack
auto a = SomeClass(arg);  // class on the heap

// Anti-default cases
auto a = SomeStruct.new(arg);  // struct on the heap
scope a = SomeClass(arg);  // class on the stack

// Placement cases
auto a = SomeStruct.new[placement_arg](arg); // placement struct
auto a = SomeClass.new[placement_arg](arg); // placement class

Not sure about those brackets.  Kind of odd-ball, but placement new is
kind of odd-ball anyway.  And I think we agreed that such syntax was
workable for templates, if not pleasant for the programmer.  But new
expressions are rarely part of mondo compound expressions, and there's
the keyword "new" to clue you in, so I think it should be acceptable
in this case.

--bb
Oct 23 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:

 How about this as a start:
 
 // Default cases
 auto a = SomeStruct(arg);  // struct on the stack
 auto a = SomeClass(arg);  // class on the heap
 
 // Anti-default cases
 auto a = SomeStruct.new(arg);  // struct on the heap
 scope a = SomeClass(arg);  // class on the stack
 
 // Placement cases
 ...


I agree that the placement new syntax can be less nice.

But for the struct/class cases I'd like something more symmetric :-)
A first silly possibility:

auto a = SomeStruct(arg); // stack
auto a = SomeStruct.new(arg); // heap
auto a = SomeStruct.pnew(placement_arg)(arg); // placement
A possible alternative:
auto a = SomeStruct.pnew(placement_arg).new(arg); // placement

auto a = SomeClass(arg); // stack
auto a = SomeClass.new(arg); // heap
auto a = SomeClass.pnew(placement_arg)(arg); // placement
A possible alternative:
auto a = SomeClass.pnew(placement_arg).new(arg); // placement

Bye,
bearophile
Oct 23 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 24, 2008 at 5:44 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Bill Baxter:

 How about this as a start:

 // Default cases
 auto a = SomeStruct(arg);  // struct on the stack
 auto a = SomeClass(arg);  // class on the heap

 // Anti-default cases
 auto a = SomeStruct.new(arg);  // struct on the heap
 scope a = SomeClass(arg);  // class on the stack

 // Placement cases
 ...


 I agree that the placement new syntax can be less nice.

 But for the struct/class cases I'd like something more symmetric :-)
 A first silly possibility:

 auto a = SomeStruct(arg); // stack
 auto a = SomeStruct.new(arg); // heap
 auto a = SomeStruct.pnew(placement_arg)(arg); // placement
 A possible alternative:
 auto a = SomeStruct.pnew(placement_arg).new(arg); // placement

 auto a = SomeClass(arg); // stack
 auto a = SomeClass.new(arg); // heap
 auto a = SomeClass.pnew(placement_arg)(arg); // placement
 A possible alternative:
 auto a = SomeClass.pnew(placement_arg).new(arg); // placement


Well, D tries to make heap classes look syntactically the same stack
structs in most cases despite the semantic differences.   "Foo x" is
either a stack struct or a heap class.   The 'x' does not look like a
pointer if it's a class, but in fact it is a pointer.  That was D's
big change over C++ -- make the *default* case for those two use the
same syntax.

So I don't see why construction should be the only place to put that
distinction in your face.  The default syntaxes look the same
elsewhere, so the default scheme for construction should look the same
for both.

Such uniformity is also going to be better for writing templates that
construct things.  Structs are more likely to be pure value types than
classes.  So if I want to write a template that does non-default
construction of an array of Things I'd rather be able to write this:

Thing[] make_thing_array(Thing, ConstructArgs...)(size_t len, ConstructArgs A)
{
       Thing[]  ret;  ret.length = len;
       foreach(ref o; ret) {  o = Thing(A); }
}

Than have to resort to static ifs all the time just to get the default behavior:

Thing[] make_thing_array(Thing, ConstructArgs...)(size_t len, ConstructArgs A)
{
       Thing[]  ret;  ret.length = len;
       static if(is(Thing : class)) {
          foreach(ref o; ret) {  o = new Thing(A); }
       }
       else {
          foreach(ref o; ret) {  o = Thing(A); }
       }
}

Put another way, I think the case of "give me default allocation for
the type" is more common in generic code than "give me heap allocation
no matter what".

So for me, the main thing I care about is making the *default*
allocation strategy use the same syntax.  Beyond that I don't really
care much what syntax is chosen.

... But here's another thought.  It doesn't really have to be me vs
you here.  Both cases do have some use.  Maybe the best thing here is
a syntax that can *either* emphasize sameness of allocation *or*
emphasize default behavior.

So then:
auto a = Class();  // heap   (default)
auto a = Struct(); // stack   (default)

auto a = Class.new(stack)(); // stack
auto a = Struct.new(stack)(); // stack

auto a = Class.new(heap)(); // heap
auto a = Struct.new(heap)(); // heap

void *addr;
auto a = Class.new(addr)(); // placement
auto a = Struct.new(addr)(); // placement

One thing to consider is that anything other than the default strategy
is really a kind of a vague placement new.  You're telling the
compiler to construct the object in some non-default memory location,
you're just not telling it exactly what the address is, just whether
the address should be in heap or stack.

In the above "heap" and "stack" are context keywords of new.

--bb
Oct 23 2008
prev sibling next sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
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);
Oct 23 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 24, 2008 at 6:28 AM, Sergey Gromov <snake.scaly 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
Oct 23 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Bill Baxter wrote:

 On Fri, Oct 24, 2008 at 6:28 AM, Sergey Gromov <snake.scaly 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...);
Oct 23 2008
parent Sergey Gromov <snake.scaly gmail.com> writes:
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 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.
Oct 24 2008
prev sibling parent reply Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:

 How about this as a start:
 
 // Default cases
 auto a = SomeStruct(arg);  // struct on the stack
 auto a = SomeClass(arg);  // class on the heap
 
 // Anti-default cases
 auto a = SomeStruct.new(arg);  // struct on the heap
 scope a = SomeClass(arg);  // class on the stack
 
 // Placement cases
 auto a = SomeStruct.new[placement_arg](arg); // placement struct
 auto a = SomeClass.new[placement_arg](arg); // placement class


I don't particularly care about getting rid of the "new" keyword. In 
fact, I especially like the part about getting rid of this little ugly:

    // uuuuuugly
    auto x = (new MyClass()).whatever();

    // holy crap. so much better.
    auto x = MyClass().whatever();

But I think it's weird that people want to retain "new" to indicate heap 
construction and use the word "scope" to indicate stack construction. 
Except for structs, which would have different rules.

Ugh.

Why not just introduce "heap" and "stack" keywords, and say it directly?

    stack auto x = MyClass();
    heap auto y = MyStruct();

...or, since "heap" and "stack" are good user keywords, maybe introduce 
an "on" keyword. Maybe something like this:

    auto x = on(stack) MyClass();
    auto y = on(heap) MyStruct();

To me, there's nothing about the "new" keyword that implies heap 
construction. "Scope" is a little bit better, because I know the memory 
will be cleaned up at the end of the scope, but that doesn't 
*necessarily* mean stack allocation, per se.

--benji
Oct 23 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 24, 2008 at 3:01 PM, Benji Smith <dlanguage benjismith.net> wrote:

 Bill Baxter wrote:

 How about this as a start:

 // Default cases
 auto a = SomeStruct(arg);  // struct on the stack
 auto a = SomeClass(arg);  // class on the heap

 // Anti-default cases
 auto a = SomeStruct.new(arg);  // struct on the heap
 scope a = SomeClass(arg);  // class on the stack

 // Placement cases
 auto a = SomeStruct.new[placement_arg](arg); // placement struct
 auto a = SomeClass.new[placement_arg](arg); // placement class


 I don't particularly care about getting rid of the "new" keyword. In fact, I
 especially like the part about getting rid of this little ugly:

   // uuuuuugly
   auto x = (new MyClass()).whatever();

   // holy crap. so much better.
   auto x = MyClass().whatever();

 But I think it's weird that people want to retain "new" to indicate heap
 construction and use the word "scope" to indicate stack construction. Except
 for structs, which would have different rules.

 Ugh.

 Why not just introduce "heap" and "stack" keywords, and say it directly?


Did you see my subsequent proposal?  I'm actually quite fond of it.
But no one has responded to it.  :-(  [Bill cry's himself a silent
tear.]


   stack auto x = MyClass();
   heap auto y = MyStruct();

 ...or, since "heap" and "stack" are good user keywords, maybe introduce an
 "on" keyword. Maybe something like this:

   auto x = on(stack) MyClass();
   auto y = on(heap) MyStruct();


That's kinda cute.    "in" would almost work there.    Too bad we
don't usually say "put it in the stack" in CS.  :-)


 To me, there's nothing about the "new" keyword that implies heap
 construction. "Scope" is a little bit better, because I know the memory will
 be cleaned up at the end of the scope, but that doesn't *necessarily* mean
 stack allocation, per se.


New is already a keyword meaning allocation/construction in D, Java,

that "new" probably has something to do with construction.  So the
question is why wouldn't you use "new"?

--bb
Oct 24 2008
parent reply Benji Smith <dlanguage benjismith.net> writes:
Bill Baxter wrote:

 On Fri, Oct 24, 2008 at 3:01 PM, Benji Smith <dlanguage benjismith.net> wrote:

 Why not just introduce "heap" and "stack" keywords, and say it directly?


 
 Did you see my subsequent proposal?  I'm actually quite fond of it.
 But no one has responded to it.  :-(  [Bill cry's himself a silent
 tear.]


You mean the one where you suggested this?

   auto a = Class();  // heap   (default)
   auto a = Struct(); // stack   (default)

   auto a = Class.new(stack)(); // stack
   auto a = Struct.new(stack)(); // stack

   auto a = Class.new(heap)(); // heap
   auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement

Yeah! I noticed it. And I like it. In fact, I thought to myself "that's 
almost the same as my idea". Generally, I'm not a fan of the consecutive 
sequence of parentheses (especially that templates already make for 
double parens; I can't imagine I'd want triple parens for a templatized 
consttructor call).

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());


 New is already a keyword meaning allocation/construction in D, Java,

 that "new" probably has something to do with construction.  So the
 question is why wouldn't you use "new"?



structs can *only* be allocated on the stack (unless they're members of 
an object, or if they're in an array).

To me, "new" is a great word for "allocate, and then invoke the 
constructor", but it doesn't have anything to do with *HEAP* allocation, 
per se.

And then I thought to myself "for chrissakes, if you want the heap or 
the stack, why not ask for it by name?"

--benji
Oct 24 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Benji Smith wrote:

 Bill Baxter wrote:

 On Fri, Oct 24, 2008 at 3:01 PM, Benji Smith 
 <dlanguage benjismith.net> wrote:

 Why not just introduce "heap" and "stack" keywords, and say it directly?


 Did you see my subsequent proposal?  I'm actually quite fond of it.
 But no one has responded to it.  :-(  [Bill cry's himself a silent
 tear.]


 
 You mean the one where you suggested this?
 
   auto a = Class();  // heap   (default)
   auto a = Struct(); // stack   (default)
 
   auto a = Class.new(stack)(); // stack
   auto a = Struct.new(stack)(); // stack
 
   auto a = Class.new(heap)(); // heap
   auto a = Struct.new(heap)(); // heap
 
   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


I strongly *oppose* using stack and heap as keywords because there are 
also (partly irrelevant) data structures called stack and heap, even 
though according to the guideline these class/structs should be named 
Stack and Heap.

And I think we can include the meaning that “scope” attribute always 
allocate on stack (Currently 4 conditions need to be met for so), but 
I'm afraid this may break something (otherwise the other 3 conditions 
won't be there?). Maybe some experts can comment on this?

(Ref: http://www.digitalmars.com/d/2.0/memory.html#stackclass)


And I suggest keeping the “new” syntax for heap ("return a pointer") 
allocation. So,

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)

auto c = new Class(...);  // on heap (compatible with current syntax)
auto s = new Struct(...); // on heap (compatible with current syntax)

auto c = new(...) Class(...);  // placement (compatible with current syntax)
auto s = new(...) Struct(...); // placement (compatible with current 
syntax?)


/* if you want symmetry, do it like this:

new c = Class(...);
new(...) c = Class(...);

kinda strange for me. */

These will cause minimum change while eliminating the “new” for most 
cases. This won't free the “new” keyword though.


 Yeah! I noticed it. And I like it. In fact, I thought to myself "that's 
 almost the same as my idea". Generally, I'm not a fan of the consecutive 
 sequence of parentheses (especially that templates already make for 
 double parens; I can't imagine I'd want triple parens for a templatized 
 consttructor call).
 
 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());
 

 New is already a keyword meaning allocation/construction in D, Java,

 that "new" probably has something to do with construction.  So the
 question is why wouldn't you use "new"?


 

 structs can *only* be allocated on the stack (unless they're members of 
 an object, or if they're in an array).
 
 To me, "new" is a great word for "allocate, and then invoke the 
 constructor", but it doesn't have anything to do with *HEAP* allocation, 
 per se.
 
 And then I thought to myself "for chrissakes, if you want the heap or 
 the stack, why not ask for it by name?"
 
 --benji
Oct 24 2008
parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there are also
 (partly irrelevant) data structures called stack and heap, even though
 according to the guideline these class/structs should be named Stack and
 Heap.


Right, that's why both Benji and I proposed making them *context*
keywords.  Just like "Windows" is a keyword only in the context of
extern( ).  This would make heap and stack keywords only in the
context of new(  ).


 And I think we can include the meaning that "scope" attribute always
 allocate on stack (Currently 4 conditions need to be met for so), but I'm
 afraid this may break something (otherwise the other 3 conditions won't be
 there?). Maybe some experts can comment on this?



 And I suggest keeping the "new" syntax for heap ("return a pointer")
 allocation. So,


Well, Andrei was looking at getting rid of this "new blah" syntax for
other reasons already, so that's why I tacked in on as a pseudomethod
of classes and structs.


 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.

Specifically as an example, say you have some object that does
comparisions and you want to pass it to a sort function then uniq it .
  First you wrote this:

     T[] array; ...
     T[] filtered = uniq(sorted(MyComparator.new, array)));

Then you decided the heap alloc was unnecessary there, so now you have
to change it all around

     T[] array; ...
     {   // made a block here so that theComparator goes away after sorting
        scope theComparator = MyComparator.new;
        T[] filtered = uniq(sorted(theComparator, array)));
     }

Instead of just sticking "(stack)" in there and being done with it:

     T[] array; ...
     T[] filtered = uniq(sorted(MyComparator.new(stack), array)));


 auto c = new Class(...);  // on heap (compatible with current syntax)
 auto s = new Struct(...); // on heap (compatible with current syntax)

 auto c = new(...) Class(...);  // placement (compatible with current syntax)
 auto s = new(...) Struct(...); // placement (compatible with current
 syntax?)


 /* 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.


 These will cause minimum change while eliminating the "new" for most cases.
 This won't free the "new" keyword though.


I don't particularly think it needs to be freed up.  A better case may
be made for, delete, though because there's less that's special about
how it works.


 Yeah! I noticed it. And I like it. In fact, I thought to myself "that's
 almost the same as my idea".




(To Benji now) Yep, it was!


 Generally, I'm not a fan of the consecutive
 sequence of parentheses (especially that templates already make for double
 parens; I can't imagine I'd want triple parens for a templatized
 consttructor call).




Well, the idea is that the versions that use "new" will be fairly
rare.  I'm certainly open to other ideas.  I suggested using [] just
for new args in another post.  Like
     MyClass.new[scope](foo,bar)
It just seems odd to me to use that in this one place and no other.  I
think the parens would work, which is why I went back to parens.

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


 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?

--bb
Oct 24 2008
next sibling parent Benji Smith <dlanguage benjismith.net> writes:
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
Oct 24 2008
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:
 

  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there are also
 (partly irrelevant) data structures called stack and heap, even though
 according to the guideline these class/structs should be named Stack and
 Heap.


 
 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).
 


I see. But with the your new(...) syntax this can't be done because it 
is ambiguous with

   void* stack = allocate();
   auto C = Class.new(stack)();

The placement new syntax should use some other syntax.


 And I think we can include the meaning that "scope" attribute always
 allocate on stack (Currently 4 conditions need to be met for so), but I'm
 afraid this may break something (otherwise the other 3 conditions won't be
 there?). Maybe some experts can comment on this?


 

 And I suggest keeping the "new" syntax for heap ("return a pointer")
 allocation. So,


 
 Well, Andrei was looking at getting rid of this "new blah" syntax for
 other reasons already, so that's why I tacked in on as a pseudomethod
 of classes and structs.
 


I know. My suggestion is not to get rid of all the new syntax but make 
it appear less frequently.


 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.
 
 Specifically as an example, say you have some object that does
 comparisions and you want to pass it to a sort function then uniq it .
   First you wrote this:
 
      T[] array; ...
      T[] filtered = uniq(sorted(MyComparator.new, array)));
 
 Then you decided the heap alloc was unnecessary there, so now you have
 to change it all around
 
      T[] array; ...
      {   // made a block here so that theComparator goes away after sorting
         scope theComparator = MyComparator.new;
         T[] filtered = uniq(sorted(theComparator, array)));
      }
 
 Instead of just sticking "(stack)" in there and being done with it:
 
      T[] array; ...
      T[] filtered = uniq(sorted(MyComparator.new(stack), array)));
 


I see. So seems we must stick with method calls.


 auto c = new Class(...);  // on heap (compatible with current syntax)
 auto s = new Struct(...); // on heap (compatible with current syntax)

 auto c = new(...) Class(...);  // placement (compatible with current syntax)
 auto s = new(...) Struct(...); // placement (compatible with current
 syntax?)


 /* 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.
 

 These will cause minimum change while eliminating the "new" for most cases.
 This won't free the "new" keyword though.


 
 I don't particularly think it needs to be freed up.  A better case may
 be made for, delete, though because there's less that's special about
 how it works.
 

 Yeah! I noticed it. And I like it. In fact, I thought to myself "that's
 almost the same as my idea".




 
 (To Benji now) Yep, it was!
 

 Generally, I'm not a fan of the consecutive
 sequence of parentheses (especially that templates already make for double
 parens; I can't imagine I'd want triple parens for a templatized
 consttructor call).




 
 Well, the idea is that the versions that use "new" will be fairly
 rare.  I'm certainly open to other ideas.  I suggested using [] just
 for new args in another post.  Like
      MyClass.new[scope](foo,bar)
 It just seems odd to me to use that in this one place and no other.  I
 think the parens would work, which is why I went back to parens.
 
 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
 

 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?
 
 --bb
Oct 25 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
KennyTM~ wrote:

 Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there 
 are also
 (partly irrelevant) data structures called stack and heap, even though
 according to the guideline these class/structs should be named Stack and
 Heap.


 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).


 
 I see. But with the your new(...) syntax this can't be done because it 
 is ambiguous with
 
   void* stack = allocate();
   auto C = Class.new(stack)();
 
 The placement new syntax should use some other syntax.
 


or do it like this:

    auto C = Class.new(placement, addr, etc)();
//--------------------^ use this to specify it is a placement new.
Oct 25 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
KennyTM~ wrote:

 KennyTM~ wrote:

 Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there
 are also
 (partly irrelevant) data structures called stack and heap, even though
 according to the guideline these class/structs should be named Stack
 and
 Heap.


 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).


 I see. But with the your new(...) syntax this can't be done because it
 is ambiguous with

   void* stack = allocate();
   auto C = Class.new(stack)();

 The placement new syntax should use some other syntax.


 
 or do it like this:
 
    auto C = Class.new(placement, addr, etc)();
 //--------------------^ use this to specify it is a placement new.


maybe just add the concept of allocators.
auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
auto C2 = Class.new(parameters, HeapAllocator); // on heap
auto C3 = Class.new(parameters, StackAllocator); // on stack
auto C4 = Class.new(parameters, MyPlacementNewAllocator);
etc..
initial Allocator hierarchy could be part of the run-time, and could be
user extended to allow for placement new.
Oct 25 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Yigal Chripun wrote:

 KennyTM~ wrote:

 KennyTM~ wrote:

 Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there
 are also
 (partly irrelevant) data structures called stack and heap, even though
 according to the guideline these class/structs should be named Stack
 and
 Heap.


 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).


 I see. But with the your new(...) syntax this can't be done because it
 is ambiguous with

   void* stack = allocate();
   auto C = Class.new(stack)();

 The placement new syntax should use some other syntax.


 or do it like this:

    auto C = Class.new(placement, addr, etc)();
 //--------------------^ use this to specify it is a placement new.


 
 maybe just add the concept of allocators.
 auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
 auto C2 = Class.new(parameters, HeapAllocator); // on heap
 auto C3 = Class.new(parameters, StackAllocator); // on stack
 auto C4 = Class.new(parameters, MyPlacementNewAllocator);
 etc..
 initial Allocator hierarchy could be part of the run-time, and could be
 user extended to allow for placement new.
 


This can't work because parameters (I bet you mean constructor arguments 
here) can be variadic.
Oct 25 2008
next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
KennyTM~ wrote:

 Yigal Chripun wrote:

 KennyTM~ wrote:

 KennyTM~ wrote:

 Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there
 are also
 (partly irrelevant) data structures called stack and heap, even
 though
 according to the guideline these class/structs should be named Stack
 and
 Heap.


 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).


 I see. But with the your new(...) syntax this can't be done because it
 is ambiguous with

   void* stack = allocate();
   auto C = Class.new(stack)();

 The placement new syntax should use some other syntax.


 or do it like this:

    auto C = Class.new(placement, addr, etc)();
 //--------------------^ use this to specify it is a placement new.


 maybe just add the concept of allocators.
 auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
 auto C2 = Class.new(parameters, HeapAllocator); // on heap
 auto C3 = Class.new(parameters, StackAllocator); // on stack
 auto C4 = Class.new(parameters, MyPlacementNewAllocator);
 etc..
 initial Allocator hierarchy could be part of the run-time, and could be
 user extended to allow for placement new.


 
 This can't work because parameters (I bet you mean constructor arguments
 here) can be variadic.


I did mean the constructor arguments. The syntax itself is less
important here, I was more talking about the concept of Allocators.
like the ones in STL, for example.

regarding the syntax:
a few possibilities that come to mind:

a) new!(Allocator)(args)..

b) Allocator is just a regular parameter which you can add to your args
list. now the c-tor need some machinery to handle the allocator.
I'd say something like:
a c-tor does two things, gets memory and puts stuff into that memory.
so the first thing a c-tor does is automatically calls a default
Allocator for the type to get memory, *unless* you call one explicitly
yourself. it's similar to the way a c-tor has an implicit super() call
if you don't call that yourself only this probably will need additional
machinery to work.

other ideas how to approach this?
Oct 25 2008
parent reply KennyTM~ <kennytm gmail.com> writes:
Yigal Chripun wrote:

 KennyTM~ wrote:

 Yigal Chripun wrote:

 KennyTM~ wrote:

 KennyTM~ wrote:

 Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there
 are also
 (partly irrelevant) data structures called stack and heap, even
 though
 according to the guideline these class/structs should be named Stack
 and
 Heap.


 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).


 I see. But with the your new(...) syntax this can't be done because it
 is ambiguous with

   void* stack = allocate();
   auto C = Class.new(stack)();

 The placement new syntax should use some other syntax.


 or do it like this:

    auto C = Class.new(placement, addr, etc)();
 //--------------------^ use this to specify it is a placement new.


 maybe just add the concept of allocators.
 auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
 auto C2 = Class.new(parameters, HeapAllocator); // on heap
 auto C3 = Class.new(parameters, StackAllocator); // on stack
 auto C4 = Class.new(parameters, MyPlacementNewAllocator);
 etc..
 initial Allocator hierarchy could be part of the run-time, and could be
 user extended to allow for placement new.


 This can't work because parameters (I bet you mean constructor arguments
 here) can be variadic.


 
 I did mean the constructor arguments. The syntax itself is less
 important here, I was more talking about the concept of Allocators.
 like the ones in STL, for example.
 
 regarding the syntax:
 a few possibilities that come to mind:
 
 a) new!(Allocator)(args)..


Then Allocator must be known in compile time? Though also in STL.


 
 b) Allocator is just a regular parameter which you can add to your args
 list. now the c-tor need some machinery to handle the allocator.
 I'd say something like:
 a c-tor does two things, gets memory and puts stuff into that memory.
 so the first thing a c-tor does is automatically calls a default
 Allocator for the type to get memory, *unless* you call one explicitly
 yourself. it's similar to the way a c-tor has an implicit super() call
 if you don't call that yourself only this probably will need additional
 machinery to work.


Yes. Although the problem right now is syntactical. :(


 
 other ideas how to approach this?
 


Use the semicolon:

   Class.new(parameters; allocator params);
Oct 25 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
KennyTM~ wrote:

 Yigal Chripun wrote:

 KennyTM~ wrote:

 Yigal Chripun wrote:

 KennyTM~ wrote:

 KennyTM~ wrote:

 Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there
 are also
 (partly irrelevant) data structures called stack and heap, even
 though
 according to the guideline these class/structs should be named
 Stack
 and
 Heap.


 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).


 I see. But with the your new(...) syntax this can't be done
 because it
 is ambiguous with

   void* stack = allocate();
   auto C = Class.new(stack)();

 The placement new syntax should use some other syntax.


 or do it like this:

    auto C = Class.new(placement, addr, etc)();
 //--------------------^ use this to specify it is a placement new.


 maybe just add the concept of allocators.
 auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
 auto C2 = Class.new(parameters, HeapAllocator); // on heap
 auto C3 = Class.new(parameters, StackAllocator); // on stack
 auto C4 = Class.new(parameters, MyPlacementNewAllocator);
 etc..
 initial Allocator hierarchy could be part of the run-time, and could be
 user extended to allow for placement new.


 This can't work because parameters (I bet you mean constructor arguments
 here) can be variadic.


 I did mean the constructor arguments. The syntax itself is less
 important here, I was more talking about the concept of Allocators.
 like the ones in STL, for example.

 regarding the syntax:
 a few possibilities that come to mind:

 a) new!(Allocator)(args)..


 
 Then Allocator must be known in compile time? Though also in STL.
 

 b) Allocator is just a regular parameter which you can add to your args
 list. now the c-tor need some machinery to handle the allocator.
 I'd say something like:
 a c-tor does two things, gets memory and puts stuff into that memory.
 so the first thing a c-tor does is automatically calls a default
 Allocator for the type to get memory, *unless* you call one explicitly
 yourself. it's similar to the way a c-tor has an implicit super() call
 if you don't call that yourself only this probably will need additional
 machinery to work.


 
 Yes. Although the problem right now is syntactical. :(
 

 other ideas how to approach this?


 
 Use the semicolon:
 
   Class.new(parameters; allocator params);


if there's an allocator object, you don't need the above. just pass the
extra params to the alloc object itself and not the C-tor.
i.e: Class.new(params, Allocator(params));

extended example:

SharedMemoryAllocator shmAlloc(params);
auto a = ClassA.new(params, shmAlloc);
auto b = ClassB.new(params, shmAlloc);
auto c = StructA.new(params, shmAlloc);
auto d = ClassC.new(params); // default Class Allocator (on heap)
auto e = Struct.new(params); // default Struct Allocator (on stack)
auto d = ClassC.new(params, StackAlloc); // on stack
auto e = Struct.new(params, GCAlloc); // on heap

something like that will require the compiler/runtime to recognize the
allocator interface as special I think...
Oct 25 2008
parent KennyTM~ <kennytm gmail.com> writes:
Yigal Chripun wrote:

 KennyTM~ wrote:

 Yigal Chripun wrote:

 KennyTM~ wrote:

 Yigal Chripun wrote:

 KennyTM~ wrote:

 KennyTM~ wrote:

 Bill Baxter wrote:

 On Sat, Oct 25, 2008 at 2:04 AM, KennyTM~ <kennytm gmail.com> wrote:


  auto a = Class();  // heap   (default)
  auto a = Struct(); // stack   (default)

  auto a = Class.new(stack)(); // stack
  auto a = Struct.new(stack)(); // stack

  auto a = Class.new(heap)(); // heap
  auto a = Struct.new(heap)(); // heap

   void *addr;
   auto a = Class.new(addr)(); // placement
   auto a = Struct.new(addr)(); // placement


 I strongly *oppose* using stack and heap as keywords because there
 are also
 (partly irrelevant) data structures called stack and heap, even
 though
 according to the guideline these class/structs should be named
 Stack
 and
 Heap.


 Right, that's why both Benji and I proposed making them *context*
 keywords.  Just like "Windows" is a keyword only in the context of
 extern( ).  This would make heap and stack keywords only in the
 context of new(  ).


 I see. But with the your new(...) syntax this can't be done
 because it
 is ambiguous with

   void* stack = allocate();
   auto C = Class.new(stack)();

 The placement new syntax should use some other syntax.


 or do it like this:

    auto C = Class.new(placement, addr, etc)();
 //--------------------^ use this to specify it is a placement new.


 maybe just add the concept of allocators.
 auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
 auto C2 = Class.new(parameters, HeapAllocator); // on heap
 auto C3 = Class.new(parameters, StackAllocator); // on stack
 auto C4 = Class.new(parameters, MyPlacementNewAllocator);
 etc..
 initial Allocator hierarchy could be part of the run-time, and could be
 user extended to allow for placement new.


 This can't work because parameters (I bet you mean constructor arguments
 here) can be variadic.


 I did mean the constructor arguments. The syntax itself is less
 important here, I was more talking about the concept of Allocators.
 like the ones in STL, for example.

 regarding the syntax:
 a few possibilities that come to mind:

 a) new!(Allocator)(args)..


 Then Allocator must be known in compile time? Though also in STL.


 b) Allocator is just a regular parameter which you can add to your args
 list. now the c-tor need some machinery to handle the allocator.
 I'd say something like:
 a c-tor does two things, gets memory and puts stuff into that memory.
 so the first thing a c-tor does is automatically calls a default
 Allocator for the type to get memory, *unless* you call one explicitly
 yourself. it's similar to the way a c-tor has an implicit super() call
 if you don't call that yourself only this probably will need additional
 machinery to work.


 Yes. Although the problem right now is syntactical. :(


 other ideas how to approach this?


 Use the semicolon:

   Class.new(parameters; allocator params);


 
 if there's an allocator object, you don't need the above. just pass the
 extra params to the alloc object itself and not the C-tor.
 i.e: Class.new(params, Allocator(params));
 
 extended example:
 
 SharedMemoryAllocator shmAlloc(params);
 auto a = ClassA.new(params, shmAlloc);
 auto b = ClassB.new(params, shmAlloc);
 auto c = StructA.new(params, shmAlloc);
 auto d = ClassC.new(params); // default Class Allocator (on heap)
 auto e = Struct.new(params); // default Struct Allocator (on stack)
 auto d = ClassC.new(params, StackAlloc); // on stack
 auto e = Struct.new(params, GCAlloc); // on heap
 
 something like that will require the compiler/runtime to recognize the
 allocator interface as special I think...
 
 


What if the constructor may take the allocator object as its argument?

class X {
    string t;
    this(string x, Allocator alc = Allocator.init) {
       t = x ~ alc.toString();   // why not?
    }
}

SharedMemoryAllocator shmAlloc(alloc_params);
auto x = X.new("abc", shmAlloc);   // what I'm calling?

The semi-colon version disambiguates this situation.
Oct 25 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Sat, Oct 25, 2008 at 11:03 PM, KennyTM~ <kennytm gmail.com> wrote:


   auto C = Class.new(placement, addr, etc)();
 //--------------------^ use this to specify it is a placement new.






Yeh, I was thinking that was a possibility too, if  .new(heap,a)
.new(stack,a) and .new(a) weren't sufficiently distinct.
I was thinking to call it  .new(place,a), though.  But same idea.


 maybe just add the concept of allocators.
 auto C1 = Class.new(parameters/*, Allocator = GC.DefaultAllocator */);
 auto C2 = Class.new(parameters, HeapAllocator); // on heap
 auto C3 = Class.new(parameters, StackAllocator); // on stack
 auto C4 = Class.new(parameters, MyPlacementNewAllocator);
 etc..
 initial Allocator hierarchy could be part of the run-time, and could be
 user extended to allow for placement new.


 This can't work because parameters (I bet you mean constructor arguments
 here) can be variadic.


You could fix that by putting the allocator first, or attach params to
the allocator

    auto C4 = Class.new(MyPlacementNewAllocator(parameters))

The bigger concern to me is that StackAllocator can't be just a
regular allocator.  The compiler would have to recognize that
StackAllocator was being used and reserve the appropriate space on the
stack, and then pass that stack address to the StackAllocator somehow.
 It's not impossible but it sounds messy from the implementation
perspective.  And I find it kind of jarring that the three modes look
similar, but one is actually invoking deep compiler magic while the
other two are just regular Joes.

--bb
Oct 25 2008
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article

 It kills static opCall for classes, but who cares.


Actually, I sometimes use static opCall to encapsulate the creation of temp
variables that I might want to recycle for performance reasons in some cases,
though more likely with a struct than with a class.  Example:

SomeType foo() {
    auto temp = new SomeType[someNumber];
    doStuff;
    return someStuff;
}

would become:

struct foo {
    SomeType[] temp;

    static opCall() {
        //Creates a foo, simulates a regular function call.
        //Good for when I don't care about recycling temp storage.
        foo f;
        return f.doStuff;
    }

    SomeType doStuff() {
        temp.length = someNumber;  //Only allocates first time.
        doStuff;
        return temp;
    }
}

This way, I can either use it the clean, easy way via the static opCall
simulating
a regular function call, or the efficient way by making an explicit instance of
the struct, and doStuff() in a loop.
Oct 23 2008
parent "Bill Baxter" <wbaxter gmail.com> writes:
On Fri, Oct 24, 2008 at 5:55 AM, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Bill Baxter (wbaxter gmail.com)'s article

 It kills static opCall for classes, but who cares.


 Actually, I sometimes use static opCall to encapsulate the creation of temp
 variables that I might want to recycle for performance reasons in some cases,
 though more likely with a struct than with a class.  Example:

 SomeType foo() {
    auto temp = new SomeType[someNumber];
    doStuff;
    return someStuff;
 }

 would become:

 struct foo {
    SomeType[] temp;

    static opCall() {
        //Creates a foo, simulates a regular function call.
        //Good for when I don't care about recycling temp storage.
        foo f;
        return f.doStuff;
    }

    SomeType doStuff() {
        temp.length = someNumber;  //Only allocates first time.
        doStuff;
        return temp;
    }
 }

 This way, I can either use it the clean, easy way via the static opCall
simulating
 a regular function call, or the efficient way by making an explicit instance of
 the struct, and doStuff() in a loop.


There are definitely uses for static opCall, but it's all just for
cuteness' sake.  There's no reason you can't use a regular static
method instead.  Like

        temp.length = someNumber.tmp;  // static method call, only
allocates first time

--bb
Oct 23 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
On Thu, Oct 23, 2008 at 8:47 PM, Yigal Chripun <yigal100 gmail.com> wrote:

 Bill Baxter wrote:

 On Thu, Oct 23, 2008 at 6:32 PM, bearophile
 <bearophileHUGS lycos.com> wrote:

 In Python to create new instances of a class you use the normal
 function call syntax, this allows you to use them as factory
 functions:

 class C: def __init__(self, id): self.id = id def __repr__(self):
 return "<%s>" % self.id seq = map(C, [1, -5, 10, 3])

 That creates an array (list) of four objects.

 In D with a map() you can do something similar:

 import d.all; import std.string: format;

 class C { int id; this(int id) { this.id = id; } string toString()
 { return format("<%s>", this.id); } static C opCall(int id) {
 return new C(id); } } void main() { auto seq = map((int id){return
 new C(id);}, [1, -5, 10, 3]); putr(seq); }

 You can use the opCall method in a more direct way:

 auto seq2 = map(&(C.opCall), [1, -5, 10, 3]); putr(seq2);

 But probably even better is to replace the current new syntax with
 a class method that creates the instances (I think the Ruby
 language has such syntax):

 auto seq3 = map(C.new, [1, -5, 10, 3]); putr(seq3);


 That would be  map(&(C.new), [1,-5,10,3]); wouldn't it?


 With that normal code like:

 new Foo(10, 20)

 becomes:

 Foo.new(10, 20)

 Not a big change but allows a more functional style of coding.


 I like it.   Can we get rid of delete's specialness too?

 Maybe just    delete(anInstance); Make it like a normal function too.
 Enabling things like

 map(&delete, [obj1, obj2, obj3])

 --bb


 Andrei already mentioned that he wants to get read of new/delete IIRC.
 I like Ruby's way of making it regular methods. something like:
 obj.new(..) and obj.delete()
 but, how do you specify stack vs heap allocation?
 something like:
 auto a = new S(); //on heap
 auto b = S(); //on stack

 also, what about placement new?


Hmm, I didn't realize D had a placement new.  But clearly it does and
more -- you can pass args to new to control the allocator.
  http://www.digitalmars.com/d/2.0/class.html
  look for "Class Allocators".
also
  http://www.digitalmars.com/d/2.0/memory.html#newdelete

So simply saying make it Obj.new(args) won't cut it.  You need to be
able to do something like
    Obj.new(newargs)(constructorargs)
also.

--bb
Oct 23 2008