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