• Kristian (20/20) Aug 24 2006 How about this:
• Oskar Linde (5/18) Aug 24 2006 You can already do:
• Kristian (13/27) Aug 24 2006 s, =
• BCS (8/44) Aug 24 2006 IIRC this works:
• Kristian (33/72) Aug 24 2006 valid =
• BCS (6/19) Aug 24 2006 that can be a bit of a gotcha. I haven't done it but putting in a
• Kristian (9/25) Aug 24 2006 =
• Ivan Senji (5/36) Aug 24 2006 Well true, but
• Kristian (13/73) Aug 24 2006 o =
• =?ISO-8859-15?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?= (14/22) Aug 25 2006 For such cases, there is the typeof() operator :
• Ivan Senji (11/28) Aug 25 2006 Why that when this works:
• Kristian (20/42) Aug 25 2006 Well yes, but you missed my point though.
• =?ISO-8859-15?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?= (15/71) Aug 25 2006 Thus it has nothing to do with syntax : it's more about documenting
• freeagle (10/43) Aug 24 2006 And if you want to create object of inherited class and store it into
• Kristian (12/51) Aug 24 2006 alid =
• Chris Nicholson-Sauls (3/26) Aug 24 2006 Would this pose any ambiguities with custom class allocators?
• Sean Kelly (5/31) Aug 24 2006 I was wondering the same thing, but I think it could be resolved via
• Kristian (24/53) Aug 25 2006 of =

Kristian <kjkilpi gmail.com> writes:

How about this:

     Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);

could be reduced to:

     Obj obj1 =3D new;
     Obj obj2 =3D new(10);

This way only one class name would be required per variable. (That is, o=
ne  =

at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also valid of cours=
e.)  =

Redundance would be reduced.

I know, it looked quite 'odd' for me too at first, but now it looks very=
  =

natural, and even clearer than the longer way.


I'm not sure if using of this syntax should be possible outside the  =

variable declarations. Later in a code "obj1 =3D new;" is less informati=
ve  =

than "obj1 =3D new Obj;". However, someone may like it too... it's up to=
 a  =

programmer how to code (which is not always a good thing(tm) though).

Oskar Linde <oskar.lindeREM OVEgmail.com> writes:

Kristian wrote:
 How about this:
 
     Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
 
 could be reduced to:
 
     Obj obj1 = new;
     Obj obj2 = new(10);
 
 This way only one class name would be required per variable. (That is, 
 one at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of 
 course.) Redundance would be reduced.

You can already do:

auto obj1 = new Obj;
auto obj2 = new Obj(10);

which takes care of the redundant Obj.

Kristian <kjkilpi gmail.com> writes:

On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde  =

<oskar.lindeREM OVEgmail.com> wrote:

 Kristian wrote:
 How about this:
      Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);
  could be reduced to:
      Obj obj1 =3D new;
     Obj obj2 =3D new(10);
  This way only one class name would be required per variable. (That i=


s,  =

 one at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also valid o=


f  =

 course.) Redundance would be reduced.

 You can already do:

 auto obj1 =3D new Obj;
 auto obj2 =3D new Obj(10);

 which takes care of the redundant Obj.

Yes, and it's nice.
But you cannot always use auto.

Obj func() {
     Obj ret =3D new;

     ret.doSomething();
     ...
     return(ret);
}

That would be nice too. :)

BCS <BCS pathlink.com> writes:

Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde  
 <oskar.lindeREM OVEgmail.com> wrote:
 
 Kristian wrote:

 How about this:
      Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
  could be reduced to:
      Obj obj1 = new;
     Obj obj2 = new(10);
  This way only one class name would be required per variable. (That 
 is,  one at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid 
 of  course.) Redundance would be reduced.


 You can already do:

 auto obj1 = new Obj;
 auto obj2 = new Obj(10);

 which takes care of the redundant Obj.

 
 
 Yes, and it's nice.
 But you cannot always use auto.
 
 Obj func() {
     Obj ret = new;
 
     ret.doSomething();
     ...
     return(ret);
 }
 
 That would be nice too. :)

IIRC this works:

Obj func() {
     auto ret = new Obj;

     ret.doSomething();
     ...
     return(ret);
}

Kristian <kjkilpi gmail.com> writes:

On Thu, 24 Aug 2006 19:08:22 +0300, BCS <BCS pathlink.com> wrote:

 Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde   =


 <oskar.lindeREM OVEgmail.com> wrote:

 Kristian wrote:

 How about this:
      Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);
  could be reduced to:
      Obj obj1 =3D new;
     Obj obj2 =3D new(10);
  This way only one class name would be required per variable. (That=




  =

 is,  one at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also =




valid  =

 of  course.) Redundance would be reduced.


 You can already do:

 auto obj1 =3D new Obj;
 auto obj2 =3D new Obj(10);

 which takes care of the redundant Obj.

   Yes, and it's nice.
 But you cannot always use auto.
  Obj func() {
     Obj ret =3D new;
      ret.doSomething();
     ...
     return(ret);
 }
  That would be nice too. :)

 IIRC this works:

 Obj func() {
      auto ret =3D new Obj;

      ret.doSomething();
      ...
      return(ret);
 }

It seems that you're right. Thanks for pointing it out. :)

However, I don't think that it's not good programming style to use auto =
a  =

lot. :/

Consider the following:

Obj func2() {...}

void func() {
     auto obj =3D func2();
}

When looking at 'func()' only it's impossible to know the type of 'obj'.=


Of course I could write "auto Obj obj" or "Obj obj", but it's inconsiste=
nt  =

with 'anonymous autos':

void func() {
     auto Obj obj1 =3D func();
     auto obj2 =3D new Obj;
}

I would really prefer the following:

void func() {
     Obj obj1 =3D func();
     Obj obj2 =3D new;
     Obj obj3;
}

Or:

void func() {
     auto Obj obj1 =3D func();
     auto Obj obj2 =3D new;
     auto Obj obj3;
}

(Note the usage of the shortcut of 'new'.)

BCS <BCS pathlink.com> writes:

Kristian wrote:
 
 However, I don't think that it's good programming style to use auto 
 a  lot. :/
 

substitute excessive for a lot and I agree.

 Consider the following:
 
 Obj func2() {...}
 
 void func() {
     auto obj = func2();
 }
 
 When looking at 'func()' only it's impossible to know the type of 'obj'.

that can be a bit of a gotcha. I haven't done it but putting in a

static assert(is(obj : Obj));

could serve as a bit of type documentation and as a guard against API 
changes.

Kristian <kjkilpi gmail.com> writes:

On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS pathlink.com> wrote:

 Kristian wrote:
  However, I don't think that it's good programming style to use auto =


a   =

 lot. :/

 substitute excessive for a lot and I agree.

 Consider the following:
  Obj func2() {...}
  void func() {
     auto obj =3D func2();
 }
  When looking at 'func()' only it's impossible to know the type of  =


 'obj'.

 that can be a bit of a gotcha. I haven't done it but putting in a

 static assert(is(obj : Obj));

 could serve as a bit of type documentation and as a guard against API =

 =

 changes.

That's too hackish to my taste, and who have energy to write such long  =

statements for simple variable declarations? ;)

Better have a simple, clear way to declare a variable, haven't it?

"Obj obj =3D new;" is short, non-redundant, and it tells everybody that =
 =

'obj' is of type 'Obj'.

Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:

Kristian wrote:
 On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS pathlink.com> wrote:
 
 Kristian wrote:
  However, I don't think that it's good programming style to use auto 
 a  lot. :/

 substitute excessive for a lot and I agree.

 Consider the following:
  Obj func2() {...}
  void func() {
     auto obj = func2();
 }
  When looking at 'func()' only it's impossible to know the type of 
 'obj'.

 that can be a bit of a gotcha. I haven't done it but putting in a

 static assert(is(obj : Obj));

 could serve as a bit of type documentation and as a guard against API 
 changes.

 
 That's too hackish to my taste, and who have energy to write such long 
 statements for simple variable declarations? ;)
 
 Better have a simple, clear way to declare a variable, haven't it?
 
 "Obj obj = new;" is short, non-redundant, and it tells everybody that 
 'obj' is of type 'Obj'.

Well true, but
auto obj = new Obj();

is not much longer, also isn't redundant and it also tells everyone what 
type 'obj' is.

Kristian <kjkilpi gmail.com> writes:

On Thu, 24 Aug 2006 23:30:25 +0300, Ivan Senji  =

<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:

 Kristian wrote:
 On Thu, 24 Aug 2006 21:17:23 +0300, BCS <BCS pathlink.com> wrote:

 Kristian wrote:
  However, I don't think that it's good programming style to use aut=




o  =

 a  lot. :/

 substitute excessive for a lot and I agree.

 Consider the following:
  Obj func2() {...}
  void func() {
     auto obj =3D func2();
 }
  When looking at 'func()' only it's impossible to know the type of =




 =

 'obj'.

 that can be a bit of a gotcha. I haven't done it but putting in a

 static assert(is(obj : Obj));

 could serve as a bit of type documentation and as a guard against AP=



I  =

 changes.

  That's too hackish to my taste, and who have energy to write such lo=


ng  =

 statements for simple variable declarations? ;)
  Better have a simple, clear way to declare a variable, haven't it?
  "Obj obj =3D new;" is short, non-redundant, and it tells everybody t=


hat  =

 'obj' is of type 'Obj'.

 Well true, but
 auto obj =3D new Obj();

 is not much longer, also isn't redundant and it also tells everyone wh=

at  =

 type 'obj' is.


That's right, but it raises a matter of (in)consistence in some cases as=
 I  =

wrote in my earlier post:

 However, I don't think that it's not good programming style to use aut=

o  =

 a lot. :/

 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj =3D func2();
 }

 When looking at 'func()' only it's impossible to know the type of 'obj=

'.
 Of course I could write "auto Obj obj" or "Obj obj", but it's  =

 inconsistent with 'anonymous autos':

 void func() {
      auto Obj obj1 =3D func();
      auto obj2 =3D new Obj;
 }

 I would really prefer the following:

 void func() {
      Obj obj1 =3D func();
      Obj obj2 =3D new;
      Obj obj3;
 }

 Or:

 void func() {
      auto Obj obj1 =3D func();
      auto Obj obj2 =3D new;
      auto Obj obj3;
 }

 (Note the usage of the shortcut of 'new'.)

=?ISO-8859-15?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?= writes:

 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


For such cases, there is the typeof() operator :

Obj func2 () { ... }

void func ()
{	typeof ( func2 ) obj = func2 ();
}

And one knows exactly that obj's type is the same as func2 return type, 
and there is no mistake possible with an auto type, althought it becomes
redundant.
It does not matter that much in a dynamically typed language :

def func2 (): return Something ()

def func ():
     obj = func2 ()

It seems that there will always be some redundancy in a typed language à 
la C, nonetheless D has made great improvement.

Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:

Rémy J. A. Mouëza wrote:
 
 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


 
 For such cases, there is the typeof() operator :
 
 Obj func2 () { ... }
 
 void func ()
 {    typeof ( func2 ) obj = func2 ();
 }

Why that when this works:

void func() {
      auto obj = func2();
}

What I think Kristian was saying is that you cannot see the type from 
the above, but you can know the type if it is:

Obj obj1 = func2();
Obj obj1 = new;

While it does make sense, I don't think that "auto obj = func2();" is a 
big problem and prefer auto.

Kristian <kjkilpi gmail.com> writes:

On Fri, 25 Aug 2006 11:38:18 +0300, Rémy J. A. Mouëza  
<ray.jay.ay.moueza do.not.spam.gmail.com> wrote:

 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


 For such cases, there is the typeof() operator :

 Obj func2 () { ... }

 void func ()
 {	typeof ( func2 ) obj = func2 ();
 }

 And one knows exactly that obj's type is the same as func2 return type,  
 and there is no mistake possible with an auto type, althought it becomes
 redundant.
 It does not matter that much in a dynamically typed language :

 def func2 (): return Something ()

 def func ():
      obj = func2 ()

 It seems that there will always be some redundancy in a typed language à  
 la C, nonetheless D has made great improvement.

Well yes, but you missed my point though.

void func() {
     auto obj1 = func2();
     typeof(func2) obj2 = func2();
}

You (or someone reading the code, lets say, a year later) know that the  
type of both 'obj1' and 'obj2' are the same as the type of 'func2()'. But  
you don't know the type of 'func2()' without looking at the definion of  
'func2()' or at the docs.

Someone may argue that declaring 'Obj' in "auto obj1 = func2();" is  
redundant because 'func2()' returns 'Obj'. But that information is not  
apparent to you when you look at 'func()'. So it's not redundant code  
inside 'func()'. If you like to use 'obj1', then you have to know its  
type, of course. It's good programming style to declare the type for  
'obj1' or you may end up with code that nobody knows the types of objects  
without looking at the documention/function declarations all the time. It  
would be very painful to modify the code later, even if you do it by  
yourself.

=?ISO-8859-15?Q?=22R=E9my_J=2E_A=2E_Mou=EBza=22?= writes:

Kristian a écrit :
 On Fri, 25 Aug 2006 11:38:18 +0300, Rémy J. A. Mouëza 
 <ray.jay.ay.moueza do.not.spam.gmail.com> wrote:
 
 Kristian wrote:
 Consider the following:

 Obj func2() {...}

 void func() {
      auto obj = func2();
 }


 For such cases, there is the typeof() operator :

 Obj func2 () { ... }

 void func ()
 {    typeof ( func2 ) obj = func2 ();
 }

 And one knows exactly that obj's type is the same as func2 return 
 type, and there is no mistake possible with an auto type, althought it 
 becomes
 redundant.
 It does not matter that much in a dynamically typed language :

 def func2 (): return Something ()

 def func ():
      obj = func2 ()

 It seems that there will always be some redundancy in a typed language 
 à la C, nonetheless D has made great improvement.

 
 Well yes, but you missed my point though.
 
 void func() {
     auto obj1 = func2();
     typeof(func2) obj2 = func2();
 }
 
 You (or someone reading the code, lets say, a year later) know that the 
 type of both 'obj1' and 'obj2' are the same as the type of 'func2()'. 
 But you don't know the type of 'func2()' without looking at the definion 
 of 'func2()' or at the docs.
 
 Someone may argue that declaring 'Obj' in "auto obj1 = func2();" is 
 redundant because 'func2()' returns 'Obj'. But that information is not 
 apparent to you when you look at 'func()'. So it's not redundant code 
 inside 'func()'. If you like to use 'obj1', then you have to know its 
 type, of course. It's good programming style to declare the type for 
 'obj1' or you may end up with code that nobody knows the types of 
 objects without looking at the documention/function declarations all the 
 time. It would be very painful to modify the code later, even if you do 
 it by yourself.

Thus it has nothing to do with syntax : it's more about documenting 
one's code. I completely missed your point, indeed. My apologizes.
I sometimes code that way :

void aMethod ( Something aThing )
{	Something a = this.processIt ( this.thing );
	auto b = processIt ( aThing );
	...
}
The first line of the method is a kind of reminder to tell the reader 
about the types and the methods used. In the remaining lines, I use the 
possible shortcuts. It's a matter of discipline ( or good programming 
style ). We, programmers, too often speak about code : source code looks 
more like some kind of software text/litterature than cryptic and secret 
code that only few people can understand.

freeagle <freeagle inmail.sk> writes:

Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde 
 <oskar.lindeREM OVEgmail.com> wrote:
 
 Kristian wrote:
 How about this:
      Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
  could be reduced to:
      Obj obj1 = new;
     Obj obj2 = new(10);
  This way only one class name would be required per variable. (That 
 is, one at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid 
 of course.) Redundance would be reduced.

 You can already do:

 auto obj1 = new Obj;
 auto obj2 = new Obj(10);

 which takes care of the redundant Obj.

 
 Yes, and it's nice.
 But you cannot always use auto.
 
 Obj func() {
     Obj ret = new;
 
     ret.doSomething();
     ...
     return(ret);
 }
 
 That would be nice too. :)

And if you want to create object of inherited class and store it into 
referenco to base class??

class A
{
}

class B : A
{
}

A a = new/* B */; ??

Kristian <kjkilpi gmail.com> writes:

On Thu, 24 Aug 2006 19:06:29 +0300, freeagle <freeagle inmail.sk> wrote:=


 Kristian wrote:
 On Thu, 24 Aug 2006 18:10:12 +0300, Oskar Linde  =


 <oskar.lindeREM OVEgmail.com> wrote:

 Kristian wrote:
 How about this:
      Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);
  could be reduced to:
      Obj obj1 =3D new;
     Obj obj2 =3D new(10);
  This way only one class name would be required per variable. (That=




  =

 is, one at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also v=




alid  =

 of course.) Redundance would be reduced.

 You can already do:

 auto obj1 =3D new Obj;
 auto obj2 =3D new Obj(10);

 which takes care of the redundant Obj.

  Yes, and it's nice.
 But you cannot always use auto.
  Obj func() {
     Obj ret =3D new;
      ret.doSomething();
     ...
     return(ret);
 }
  That would be nice too. :)

 And if you want to create object of inherited class and store it into =

 =

 referenco to base class??

 class A
 {
 }

 class B : A
 {
 }

 A a =3D new/* B */; ??

If you write "A a =3D new;" it would equal to "A a =3D new A;"

If you would like to create an object of type B, then you have to use th=
e  =

longer (normal) version:

A a =3D new B;

There is no redundancy in "A a =3D new;" and "A a =3D new B;". However, =
there  =

is redundancy in "A a =3D new A;".

Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:

Kristian wrote:
 How about this:
 
     Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);
 
 could be reduced to:
 
     Obj obj1 = new;
     Obj obj2 = new(10);
 
 This way only one class name would be required per variable. (That is, 
 one  at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of 
 course.)  Redundance would be reduced.
 
 I know, it looked quite 'odd' for me too at first, but now it looks 
 very  natural, and even clearer than the longer way.
 
 
 I'm not sure if using of this syntax should be possible outside the  
 variable declarations. Later in a code "obj1 = new;" is less 
 informative  than "obj1 = new Obj;". However, someone may like it too... 
 it's up to a  programmer how to code (which is not always a good 
 thing(tm) though).

Would this pose any ambiguities with custom class allocators?

-- Chris Nicholson-Sauls

Sean Kelly <sean f4.ca> writes:

Chris Nicholson-Sauls wrote:
 Kristian wrote:
 How about this:

     Obj obj1 = new Obj;
     Obj obj2 = new Obj(10);

 could be reduced to:

     Obj obj1 = new;
     Obj obj2 = new(10);

 This way only one class name would be required per variable. (That is, 
 one  at maximum: "Obj obj1 = new, obj2 = new(10);" is also valid of 
 course.)  Redundance would be reduced.

 I know, it looked quite 'odd' for me too at first, but now it looks 
 very  natural, and even clearer than the longer way.


 I'm not sure if using of this syntax should be possible outside the  
 variable declarations. Later in a code "obj1 = new;" is less 
 informative  than "obj1 = new Obj;". However, someone may like it 
 too... it's up to a  programmer how to code (which is not always a 
 good thing(tm) though).

 
 Would this pose any ambiguities with custom class allocators?

I was wondering the same thing, but I think it could be resolved via 
look-ahead.  That said, I'm not sure I like the syntax as it seems a bit 
confusing.  Is it really so hard to specify the type name?


Sean

Kristian <kjkilpi gmail.com> writes:

On Fri, 25 Aug 2006 00:01:46 +0300, Sean Kelly <sean f4.ca> wrote:
 Chris Nicholson-Sauls wrote:
 Kristian wrote:
 How about this:

     Obj obj1 =3D new Obj;
     Obj obj2 =3D new Obj(10);

 could be reduced to:

     Obj obj1 =3D new;
     Obj obj2 =3D new(10);

 This way only one class name would be required per variable. (That i=



s,  =

 one  at maximum: "Obj obj1 =3D new, obj2 =3D new(10);" is also valid=



 of  =

 course.)  Redundance would be reduced.

 I know, it looked quite 'odd' for me too at first, but now it looks =



 =

 very  natural, and even clearer than the longer way.


 I'm not sure if using of this syntax should be possible outside the =



  =

 variable declarations. Later in a code "obj1 =3D new;" is less  =



 informative  than "obj1 =3D new Obj;". However, someone may like it =



 =

 too... it's up to a  programmer how to code (which is not always a  =



 good thing(tm) though).

  Would this pose any ambiguities with custom class allocators?

 I was wondering the same thing, but I think it could be resolved via  =

 look-ahead.  That said, I'm not sure I like the syntax as it seems a b=

it  =

 confusing.  Is it really so hard to specify the type name?

Never underestimate the power of the dark laziness! But seriously... One=
  =

could also ask why 'this' is used in constructors/destructors instead of=
  =

the class name. I was very pleased to find out that D does that.

In Qt, for instance, you normally use pointers to objects. So, every tim=
e  =

I wrote "X ... X" (e.g. "QCanvasPolygonalItem *item =3D new  =

QCanvasPolygonalItem;") I was thinking that there must be a better way t=
o  =

do that.


I started to use a new, bigger monitor a while ago. There was a negative=
  =

side to it, however, paying money. And I thought I don't need it, not  =

really, the old one has served me fine in the past... Well, now I wouldn=
't  =

switch back to the old one.