www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Eliminate "new" for class object creation?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'm having a hard time justifying that you use

new X(args)

to create a class object, and

X(args)

to create a struct object. I wrote this:

============
The syntactic  difference between  the expression creating  a  struct 
object---Test( \meta{args} ) ---and the  expression creating a  class 
object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
could have dropped the  new   keyword entirely, but that  new  reminds
the programmer that an object allocation (i.e., nontrivial work) takes
place.
===============

I'm unhappy about that explanation because the distinction is indeed 
very weak. The constructor of a struct could also do unbounded amounts 
of work, so what gives?

I hereby suggest we get rid of new for class object creation. What do 
you guys think?


Andrei
Oct 19 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 I'm having a hard time justifying that you use
 new X(args)
 to create a class object, and
 X(args)
 to create a struct object. I wrote this:
 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============
 I'm unhappy about that explanation because the distinction is indeed
 very weak. The constructor of a struct could also do unbounded amounts
 of work, so what gives?
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?
 Andrei

Absolutely. I've thought this for a while but hesitated to bring it up because I felt it was a bikeshed issue. Now that I think of it, though, it would have the substantive benefit of making it easier to switch from structs to classes if you suddenly realize you need polymorphism, or from classes to structs if you suddenly realize you need value semantics. I really can't see any downside other than the loss of static opCall for classes, which doesn't have tons of good use cases anyhow.
Oct 19 2009
next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 19 Oct 2009 18:45:01 -0400, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s  
 article
 I'm having a hard time justifying that you use
 new X(args)
 to create a class object, and
 X(args)
 to create a struct object. I wrote this:
 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============
 I'm unhappy about that explanation because the distinction is indeed
 very weak. The constructor of a struct could also do unbounded amounts
 of work, so what gives?
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?
 Andrei

Absolutely. I've thought this for a while but hesitated to bring it up because I felt it was a bikeshed issue. Now that I think of it, though, it would have the substantive benefit of making it easier to switch from structs to classes if you suddenly realize you need polymorphism, or from classes to structs if you suddenly realize you need value semantics. I really can't see any downside other than the loss of static opCall for classes, which doesn't have tons of good use cases anyhow.

As structs mix static opCall and ctors, there's no reason classes can't.
Oct 19 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Brad Roberts wrote:
 Why do we still have static opcall?  What role does it play that ctors don't?

Return "new C" for classes for consistency with structs :o). class C { static opCall(T...)(T args) { return new C(args); } ... } Andrei
Oct 19 2009
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
Robert Jacques wrote:
 On Mon, 19 Oct 2009 18:45:01 -0400, dsimcha <dsimcha yahoo.com> wrote:
 
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 I'm having a hard time justifying that you use
 new X(args)
 to create a class object, and
 X(args)
 to create a struct object. I wrote this:
 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============
 I'm unhappy about that explanation because the distinction is indeed
 very weak. The constructor of a struct could also do unbounded amounts
 of work, so what gives?
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?
 Andrei

Absolutely. I've thought this for a while but hesitated to bring it up because I felt it was a bikeshed issue. Now that I think of it, though, it would have the substantive benefit of making it easier to switch from structs to classes if you suddenly realize you need polymorphism, or from classes to structs if you suddenly realize you need value semantics. I really can't see any downside other than the loss of static opCall for classes, which doesn't have tons of good use cases anyhow.

As structs mix static opCall and ctors, there's no reason classes can't.

Why do we still have static opcall? What role does it play that ctors don't?
Oct 19 2009
prev sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Mon, 19 Oct 2009 22:53:23 -0400, Brad Roberts <braddr puremagic.com>  
wrote:

 Robert Jacques wrote:
 On Mon, 19 Oct 2009 18:45:01 -0400, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s
 article
 I'm having a hard time justifying that you use
 new X(args)
 to create a class object, and
 X(args)
 to create a struct object. I wrote this:
 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============
 I'm unhappy about that explanation because the distinction is indeed
 very weak. The constructor of a struct could also do unbounded amounts
 of work, so what gives?
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?
 Andrei

Absolutely. I've thought this for a while but hesitated to bring it up because I felt it was a bikeshed issue. Now that I think of it, though, it would have the substantive benefit of making it easier to switch from structs to classes if you suddenly realize you need polymorphism, or from classes to structs if you suddenly realize you need value semantics. I really can't see any downside other than the loss of static opCall for classes, which doesn't have tons of good use cases anyhow.

As structs mix static opCall and ctors, there's no reason classes can't.

Why do we still have static opcall? What role does it play that ctors don't?

Well, when you want it to return something other than a new instance. The only practical example I have is for singleton-types implemented using static (TLS) variables. Also, there was a recent bug/regression with regard to struct ctors vs opCall. Though I think it's been fixed.
Oct 19 2009
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Mon, Oct 19, 2009 at 05:38:13PM -0500, Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do 
 you guys think?

Didn't we go over this a few weeks ago? I think my preference would be a bunch of templates in phobos that take new's job, and can also do different allocation strategies. The generic garbage collected one could even be called new, so auto a = new Whatever(...); can just become: auto a = new!Whatever(...); It'd be an easy enough change for users from C++ etc. to get used to and has lots of potential for improvement down the line without changing the language anymore.
 
 
 Andrei

-- Adam D. Ruppe http://arsdnet.net
Oct 19 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 20 Oct 2009 02:38:13 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 I'm having a hard time justifying that you use

 new X(args)

 to create a class object, and

 X(args)

 to create a struct object. I wrote this:

 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============

 I'm unhappy about that explanation because the distinction is indeed  
 very weak. The constructor of a struct could also do unbounded amounts  
 of work, so what gives?

 I hereby suggest we get rid of new for class object creation. What do  
 you guys think?


 Andrei

This is tricky. How would you explain that the following Test test; initializes a variable if it is struct, but doesn't initialize if it's a class? (*hint* non-nullable and explicit initialization *hint*) test.foo(); // why is my newly-created class object segfaulting but struct doesn't?
Oct 19 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Denis Koroskin wrote:
 On Tue, 20 Oct 2009 02:38:13 +0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 
 I'm having a hard time justifying that you use

 new X(args)

 to create a class object, and

 X(args)

 to create a struct object. I wrote this:

 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============

 I'm unhappy about that explanation because the distinction is indeed 
 very weak. The constructor of a struct could also do unbounded amounts 
 of work, so what gives?

 I hereby suggest we get rid of new for class object creation. What do 
 you guys think?


 Andrei

This is tricky. How would you explain that the following Test test; initializes a variable if it is struct, but doesn't initialize if it's a class? (*hint* non-nullable and explicit initialization *hint*) test.foo(); // why is my newly-created class object segfaulting but struct doesn't?

That's a good point, thanks. Andrei
Oct 19 2009
prev sibling next sibling parent Yigal Chripun <yigal100 gmail.com> writes:
On 20/10/2009 00:38, Andrei Alexandrescu wrote:
 I'm having a hard time justifying that you use

 new X(args)

 to create a class object, and

 X(args)

 to create a struct object. I wrote this:

 ============
 The syntactic difference between the expression creating a  struct 
 object---Test( \meta{args} ) ---and the expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be jarring at first. \dee
 could have dropped the  new  keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============

 I'm unhappy about that explanation because the distinction is indeed
 very weak. The constructor of a struct could also do unbounded amounts
 of work, so what gives?

 I hereby suggest we get rid of new for class object creation. What do
 you guys think?


 Andrei

I'm all for it. I'd like to see something like: class Foo; auto obj = Foo.new(args); I'd like to see a design where new allows polymorphism and different allocation schemes - basically fix all the problems as described in that Java article "what's wrong with new".
Oct 19 2009
prev sibling next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

*applause* 'X(x)' and 'new X(x)' have distinct meanings in C++. In Java/C#/D, the 'new' is just line noise. -- Rainer Deyke - rainerd eldwood.com
Oct 19 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

*applause* 'X(x)' and 'new X(x)' have distinct meanings in C++. =A0In Java/C#/D, the 'new' is just line noise.

Well, I think "new Foo" is how you create a struct on the heap in D. So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb
Oct 19 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
Bill Baxter wrote:
 On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 'X(x)' and 'new X(x)' have distinct meanings in C++.  In Java/C#/D, the
 'new' is just line noise.

Well, I think "new Foo" is how you create a struct on the heap in D. So it's not exactly line noise.

I should have specified, "for classes". -- Rainer Deyke - rainerd eldwood.com
Oct 19 2009
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter Wrote:

 On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

*applause* 'X(x)' and 'new X(x)' have distinct meanings in C++. In Java/C#/D, the 'new' is just line noise.

Well, I think "new Foo" is how you create a struct on the heap in D. So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb

Actually, new can also be used for creating classes on the stack... scope T t = new T();
Oct 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Jason House, el 19 de octubre a las 22:20 me escribiste:
 Bill Baxter Wrote:

 On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

'X(x)' and 'new X(x)' have distinct meanings in C++. ?In Java/C#/D, the 'new' is just line noise.

So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb

scope T t = new T();

Damn! This is getting confusing. It seems like allocation should be revised altogether :)

Scope will go (and this time I'm not kidding). It's very unsafe. Andrei
Oct 19 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Leandro Lucarella wrote:
 Jason House, el 19 de octubre a las 22:20 me escribiste:
 Bill Baxter Wrote:

 On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

'X(x)' and 'new X(x)' have distinct meanings in C++. ?In Java/C#/D, the 'new' is just line noise.

So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb

scope T t = new T();

Damn! This is getting confusing. It seems like allocation should be revised altogether :)

Andrei

But we need a reasonable way of allocating class instances on the stack as an optimization. Scope provides a nice way to do that. In general, I'm sick of hearing about safety. D is a close-to-the-metal systems language. The programmer has to be given control. In general I think we're going waaaay off the deep edge trying to make D too safe lately at the expense of convenience and performance.
Oct 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Leandro Lucarella wrote:
 Jason House, el 19 de octubre a las 22:20 me escribiste:
 Bill Baxter Wrote:

 On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

'X(x)' and 'new X(x)' have distinct meanings in C++. ?In Java/C#/D, the 'new' is just line noise.

So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb

scope T t = new T();

revised altogether :)

Andrei

But we need a reasonable way of allocating class instances on the stack as an optimization. Scope provides a nice way to do that. In general, I'm sick of hearing about safety. D is a close-to-the-metal systems language. The programmer has to be given control. In general I think we're going waaaay off the deep edge trying to make D too safe lately at the expense of convenience and performance.

No problem. You will be able to use InSitu!T. It is much better to confine unsafe features to libraries instead of putting them in the language. { auto foo = InSitu!(Foo)(args); // use foo ... // foo goes away } I am sorry you're sick of hearing about safety, but most everybody is sick of hearing about undefined behavior. I think D will have a landslide advantage over C++ when it will be able to define a safe subset. Andrei
Oct 19 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Leandro Lucarella wrote:
 Andrei Alexandrescu, el 19 de octubre a las 22:16 me escribiste:
 dsimcha wrote:
 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Leandro Lucarella wrote:
 Jason House, el 19 de octubre a las 22:20 me escribiste:
 Bill Baxter Wrote:

 On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

'X(x)' and 'new X(x)' have distinct meanings in C++. ?In Java/C#/D, the 'new' is just line noise.

So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb

scope T t = new T();

revised altogether :)

Andrei

optimization. Scope provides a nice way to do that. In general, I'm sick of hearing about safety. D is a close-to-the-metal systems language. The programmer has to be given control. In general I think we're going waaaay off the deep edge trying to make D too safe lately at the expense of convenience and performance.

confine unsafe features to libraries instead of putting them in the language. { auto foo = InSitu!(Foo)(args); // use foo ... // foo goes away }

<useless discussion> Why not Scoped!T ? I think the purpose for this that the lifetime of the object is bounded to the scope, right? I think is hard to figure that out from InSitu!T than Scoped!T. </useless discussion>

It's not a useless discussions, names are important. Scoped is more evocative for in-function definition, whereas InPlace/InSitu are (at least to me) more evocative when inside a class. class A { InPlace!B member; } Andrei
Oct 20 2009
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
Andrei Alexandrescu wrote:
 Leandro Lucarella wrote:
 Andrei Alexandrescu, el 19 de octubre a las 22:16 me escribiste:
 No problem. You will be able to use InSitu!T. It is much better to
 confine unsafe features to libraries instead of putting them in the
 language.

 {
     auto foo = InSitu!(Foo)(args);
     // use foo
     ...
     // foo goes away
 }

<useless discussion> Why not Scoped!T ? I think the purpose for this that the lifetime of the object is bounded to the scope, right? I think is hard to figure that out from InSitu!T than Scoped!T. </useless discussion>

It's not a useless discussions, names are important. Scoped is more evocative for in-function definition, whereas InPlace/InSitu are (at least to me) more evocative when inside a class. class A { InPlace!B member; } Andrei

InPlace actually sounds good. InSitu, while appropriate, will just sound vaguely snooty after the user looks it up in the dictionary (IMO). InPlace might seem odd in functions though. void foo(...) { InPlace!B variable; ... } In conclusion, I couldn't give a damn. ;)
Oct 20 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Jason House, el 19 de octubre a las 22:20 me escribiste:
 Bill Baxter Wrote:
 
 On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
 Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

*applause* 'X(x)' and 'new X(x)' have distinct meanings in C++. ?In Java/C#/D, the 'new' is just line noise.

Well, I think "new Foo" is how you create a struct on the heap in D. So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb

Actually, new can also be used for creating classes on the stack... scope T t = new T();

Damn! This is getting confusing. It seems like allocation should be revised altogether :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Si el enemigo se siente abatido, recuérdele que su familia está lejos y que mientras siga la pelea él se estará perdiendo el crecimiento de sus hijos. Si está feliz, recuerdele de la existencia de su familia política, en especial de los cuñados que tienen sexo con sus hermanas. -- Ricardo Vaporeso. De la desmoralización del enemigo.
Oct 19 2009
prev sibling next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Andrei Alexandrescu wrote:
 I'm having a hard time justifying that you use
 
 new X(args)
 
 to create a class object, and
 
 X(args)
 
 to create a struct object. I wrote this:
 
 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============
 
 I'm unhappy about that explanation because the distinction is indeed 
 very weak. The constructor of a struct could also do unbounded amounts 
 of work, so what gives?
 
 I hereby suggest we get rid of new for class object creation. What do 
 you guys think?
 
 
 Andrei

What would become the equivalent of, for example: new uint[][][](4, 3, 8) I can live with having to define API's for custom allocation strategies of classes and structures, rather than being able to hijack a language expression (the way one can with 'new'/'delete'), but what about the non-class new'ables? However, if we really must toss the 'new' keyword out the window, I reiterate my support for a 'T new(T,A...)(A a)' in the runtime. -- Chris Nicholson-Sauls
Oct 20 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
Chris Nicholson-Sauls Wrote:

 Andrei Alexandrescu wrote:
 I'm having a hard time justifying that you use
 
 new X(args)
 
 to create a class object, and
 
 X(args)
 
 to create a struct object. I wrote this:
 
 ============
 The syntactic  difference between  the expression creating  a  struct 
 object---Test( \meta{args} ) ---and the  expression creating a  class 
 object---\cc{new Test(}\meta{args} ) ---may be  jarring at first. \dee
 could have dropped the  new   keyword entirely, but that  new  reminds
 the programmer that an object allocation (i.e., nontrivial work) takes
 place.
 ===============
 
 I'm unhappy about that explanation because the distinction is indeed 
 very weak. The constructor of a struct could also do unbounded amounts 
 of work, so what gives?
 
 I hereby suggest we get rid of new for class object creation. What do 
 you guys think?
 
 
 Andrei

What would become the equivalent of, for example: new uint[][][](4, 3, 8) I can live with having to define API's for custom allocation strategies of classes and structures, rather than being able to hijack a language expression (the way one can with 'new'/'delete'), but what about the non-class new'ables? However, if we really must toss the 'new' keyword out the window, I reiterate my support for a 'T new(T,A...)(A a)' in the runtime. -- Chris Nicholson-Sauls

slightly ugly but: auto arr = (Array!Array!Array!int).new(4, 3, 8); //OR auto arr = MArray!(int)(4, 3, 8);
Oct 20 2009
prev sibling next sibling parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
On 20-10-2009 6:38, Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

I don't agree with this one. There's extra cost involved, and the added keyword makes that clear. Also, somebody mentioned using 'new' to allocate structs on the heap; I've never actually done that, but it sounds like using 'new' would be the perfect way to do just that. L.
Oct 20 2009
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On Tue, 20 Oct 2009 18:12:39 +0800, Lionello Lunesu
<lio lunesu.remove.com> wrote:

On 20-10-2009 6:38, Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

I don't agree with this one. There's extra cost involved, and the added keyword makes that clear. Also, somebody mentioned using 'new' to allocate structs on the heap; I've never actually done that, but it sounds like using 'new' would be the perfect way to do just that. L.

I don't think the extra cost should be emphasized with 'new' every time you instantiate a class. For example, in C#, they use 'new' for creating structs on stack (apparently to make them consistent with classes, in a silly way). I think the rarer cases when a class instance is allocated in-place (a struct on heap) can be handled by the library. BTW, why "in-situ" is better in this context than the more common "in-place"? Would be nice to know.
Oct 20 2009
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Max Samukha wrote:
 On Tue, 20 Oct 2009 18:12:39 +0800, Lionello Lunesu
 <lio lunesu.remove.com> wrote:
 
 On 20-10-2009 6:38, Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

There's extra cost involved, and the added keyword makes that clear. Also, somebody mentioned using 'new' to allocate structs on the heap; I've never actually done that, but it sounds like using 'new' would be the perfect way to do just that. L.

I don't think the extra cost should be emphasized with 'new' every time you instantiate a class. For example, in C#, they use 'new' for creating structs on stack (apparently to make them consistent with classes, in a silly way). I think the rarer cases when a class instance is allocated in-place (a struct on heap) can be handled by the library. BTW, why "in-situ" is better in this context than the more common "in-place"? Would be nice to know.

The term originated with this: class A { InSitu!B b; ... } meaning that B is embedded inside A. But I guess InPlace is just as good. Andrei
Oct 20 2009
parent =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
Andrei Alexandrescu wrote:
 Max Samukha wrote:
 On Tue, 20 Oct 2009 18:12:39 +0800, Lionello Lunesu
 <lio lunesu.remove.com> wrote:

 On 20-10-2009 6:38, Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

There's extra cost involved, and the added keyword makes that clear. Also, somebody mentioned using 'new' to allocate structs on the heap; I've never actually done that, but it sounds like using 'new' would be the perfect way to do just that. L.

I don't think the extra cost should be emphasized with 'new' every time you instantiate a class. For example, in C#, they use 'new' for creating structs on stack (apparently to make them consistent with classes, in a silly way). I think the rarer cases when a class instance is allocated in-place (a struct on heap) can be handled by the library. BTW, why "in-situ" is better in this context than the more common "in-place"? Would be nice to know.

The term originated with this: class A { InSitu!B b; ... } meaning that B is embedded inside A. But I guess InPlace is just as good. Andrei

I actually do not understand what InSitu is supposed to mean. I like the name Scope, but InPlace works for me.
Oct 20 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Lionello Lunesu wrote:
 On 20-10-2009 6:38, Andrei Alexandrescu wrote:
 I hereby suggest we get rid of new for class object creation. What do
 you guys think?

I don't agree with this one. There's extra cost involved, and the added keyword makes that clear.

That's actually one problem: a struct constructor could also execute arbitrary amounts of code, so "new" is not as informative as it might be.
 Also, somebody mentioned using 'new' to allocate structs on the heap; 
 I've never actually done that, but it sounds like using 'new' would be 
 the perfect way to do just that.

Yah, I guess I'll drop it. Andrei
Oct 20 2009
parent Rainer Deyke <rainerd eldwood.com> writes:
Andrei Alexandrescu wrote:
 Lionello Lunesu wrote:
 Also, somebody mentioned using 'new' to allocate structs on the heap;
 I've never actually done that, but it sounds like using 'new' would be
 the perfect way to do just that.

Yah, I guess I'll drop it.

Consistency with structs demands that for a class type 'X', 'new X' allocates a *reference*, not an instance, on the heap. -- Rainer Deyke - rainerd eldwood.com
Oct 20 2009
prev sibling next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 19 de octubre a las 22:16 me escribiste:
 dsimcha wrote:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
Leandro Lucarella wrote:
Jason House, el 19 de octubre a las 22:20 me escribiste:
Bill Baxter Wrote:

On Mon, Oct 19, 2009 at 4:00 PM, Rainer Deyke <rainerd eldwood.com> wrote:
Andrei Alexandrescu wrote:
I hereby suggest we get rid of new for class object creation. What do
you guys think?

'X(x)' and 'new X(x)' have distinct meanings in C++. ?In Java/C#/D, the 'new' is just line noise.

So it's not exactly line noise. I don't mind getting rid of new, but there better be a good way to allocate structs on the heap. And it better not require me to do an import just to be able to call the allocation function. I like the Foo.new syntax myself. --bb

scope T t = new T();

revised altogether :)

Andrei

But we need a reasonable way of allocating class instances on the stack as an optimization. Scope provides a nice way to do that. In general, I'm sick of hearing about safety. D is a close-to-the-metal systems language. The programmer has to be given control. In general I think we're going waaaay off the deep edge trying to make D too safe lately at the expense of convenience and performance.

No problem. You will be able to use InSitu!T. It is much better to confine unsafe features to libraries instead of putting them in the language. { auto foo = InSitu!(Foo)(args); // use foo ... // foo goes away }

<useless discussion> Why not Scoped!T ? I think the purpose for this that the lifetime of the object is bounded to the scope, right? I think is hard to figure that out from InSitu!T than Scoped!T. </useless discussion> -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- - Mire, don Inodoro! Una paloma con un anillo en la pata! Debe ser mensajera y cayó aquí! - Y... si no es mensajera es coqueta... o casada. -- Mendieta e Inodoro Pereyra
Oct 20 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Andrei Alexandrescu, el 20 de octubre a las 08:42 me escribiste:
Why not Scoped!T ? I think the purpose for this that the lifetime of the
object is bounded to the scope, right? I think is hard to figure that out
from InSitu!T than Scoped!T.

</useless discussion>

It's not a useless discussions, names are important. Scoped is more

OK, let's continue then... ;)
 evocative for in-function definition, whereas InPlace/InSitu are (at
 least to me) more evocative when inside a class.
 
 class A {
    InPlace!B member;
 }

Yes, but I think Scoped!T is clearer in average. The member effectively live in the same scope the class does. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Si pudiera acercarme un poco más, hacia vos Te diría que me tiemblan los dos pies, cuando me mirás Si supieras todo lo que me costó, llegar Hoy sabrías que me cuesta respirar, cuando me mirás
Oct 20 2009