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.

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


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 auto a lot. :/
>
> Consider the following:
>
> Obj func2() {...}
>
> void func() {
>      auto obj = 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 = func();
>      auto obj2 = new Obj;
> }
>
> I would really prefer the following:
>
> void func() {
>      Obj obj1 = func();
>      Obj obj2 = new;
>      Obj obj3;
> }
>
> Or:
>
> void func() {
>      auto Obj obj1 = func();
>      auto Obj obj2 = new;
>      auto Obj obj3;
> }
>
> (Note the usage of the shortcut of 'new'.)

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

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 = 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?

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 time I wrote "X ... X" (e.g. "QCanvasPolygonalItem *item = new QCanvasPolygonalItem;") I was thinking that there must be a better way to 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.

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

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.

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.

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.