July 25, 2006
Walter Bright wrote:
> Derek wrote:
> 
>> On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
>>
>>> And what about double meaning of 'auto'?
>>
>>
>> In general 'auto' is a poor choice for both meanings. 'auto' is obviously
>> shorthand for automatic, but automatic what???
>> Walter, given that 'auto' as a keyword is not going to be removed from the
>> language, how can one currently declare a type-inferred variable that has
>> RAII properties?
>>
> 
> Regan Heath penned the solution I thought I'd posted a while back, but maybe I hadn't:
> 
>> class A {}
>>
>> A a = new A(); //normal
>> A a = A(); //destroyed at end of scope
>>
>> and with auto..
>>
>> auto a = new A(); //normal
>> auto a = A(); //destroyed at end of scope
>>
>> Simple, elegant, obvious (IMO) 
> 
> 

Myself I would prefer not to have that.  It creates an ambiguity between  a static opCall on A and the storage attribute.
So:

class A
{
  static A opCall() { ...do something... }
}

A a = A(); // destroyed at end of scope, or call A.opCall()?

I prefer the storage attribute have it's own keyword.  Perhaps give storage 'auto' and type inference 'var'.  For me, that makes it more obvious, since to my eyes it would be a keyword that I've never seen before and now need to look up in the spec - otherwise it's just a static opCall :(.
July 25, 2006
renox wrote:
> Andrei Khropov wrote:
>> And what about double meaning of 'auto'?
>>
>> It's a longstanding issue and changes could break lots of code, but I think it's
>> a terrible design inconsistency.
>>
>> And it also currently means that we cannot use type inference with auto classes
>> (which is also inconsistensy by itself)
>>
>> ------------------------------------------------
>> import std.stdio;
>>
>> auto class X
>> {
>> public:
>>     int _i;
>>         this(int i1)
>>     {
>>         _i = i1;
>>     }
>>         int i()
>>     {
>>         return _i;
>>     }
>>         ~this()
>>     {
>>       writefln("destructor i=",_i);     }
>> }
>>
>> void main()
>> {
>>     auto X x1 = new X(1);
>>         //auto auto x2 = new X(2); // auto1.d(28): redundant storage class 'auto'
>>         // auto x3 = new X(3); // auto1.d(30): variable auto1.main.x3 reference to
>> auto class must be auto
>>         writefln("x1.i=",x1.i);
>>     //writefln("x2.i=",x2.i);
>>     //writefln("x3.i=",x3.i);
>> }
>> ---------------------------------------------------
>>
>> Some discussion was here: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/38443
>>
>> (I personally vote for 'var' for type inference)
> 
> You have my vote too.

Nooooooooo!!!!
Am I the only person who has hundreds of local variables called 'var'?
(mostly variants in Win32 code).

A quick google search for 'var cpp' showed a million hits, a fair chunk of them are local variables in C++ code. It's a very popular variable name.
July 25, 2006
Chad J wrote:
> Walter Bright wrote:
>> Derek wrote:
>>
>>> On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
>>>
>>>> And what about double meaning of 'auto'?
>>>
>>>
>>> In general 'auto' is a poor choice for both meanings. 'auto' is obviously
>>> shorthand for automatic, but automatic what???
>>> Walter, given that 'auto' as a keyword is not going to be removed from the
>>> language, how can one currently declare a type-inferred variable that has
>>> RAII properties?
>>>
>>
>> Regan Heath penned the solution I thought I'd posted a while back, but maybe I hadn't:
>>
>>> class A {}
>>>
>>> A a = new A(); //normal
>>> A a = A(); //destroyed at end of scope
>>>
>>> and with auto..
>>>
>>> auto a = new A(); //normal
>>> auto a = A(); //destroyed at end of scope
>>>
>>> Simple, elegant, obvious (IMO) 
>>
>>
> 
> Myself I would prefer not to have that.  It creates an ambiguity between  a static opCall on A and the storage attribute.

I think "static opCall" is a hack to begin with. It's basically a workaround for structs not having constructors. For classes, there's no point in having a static opCall if Walter implements the "A()" construct.

> I prefer the storage attribute have it's own keyword.  Perhaps give storage 'auto' and type inference 'var'.  For me, that makes it more obvious, since to my eyes it would be a keyword that I've never seen before and now need to look up in the spec - otherwise it's just a static opCall :(.

I also prefer "var" to "auto" for the type inference. I don't think anybody expects "var" to be dynamically typed. Well, maybe a few. And then there's the "auto" from C++; it might confuse people if its meaning were changed.

L.
July 25, 2006
On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright <newshound@digitalmars.com> wrote:
> Derek wrote:
>> On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
>>
>>> And what about double meaning of 'auto'?
>>  In general 'auto' is a poor choice for both meanings. 'auto' is obviously
>> shorthand for automatic, but automatic what???  Walter, given that 'auto' as a keyword is not going to be removed from the
>> language, how can one currently declare a type-inferred variable that has
>> RAII properties?
>>
>
> Regan Heath penned the solution I thought I'd posted a while back, but maybe I hadn't:

I recall you posting it. I'm not sure everyone saw it. I think it got lost in the thread.

Regan
July 25, 2006
On Tue, 25 Jul 2006 12:32:52 +0300, Lionello Lunesu <lio@lunesu.remove.com> wrote:
> Chad J wrote:
>> Walter Bright wrote:
>>> Derek wrote:
>>>
>>>> On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
>>>>
>>>>> And what about double meaning of 'auto'?
>>>>
>>>>
>>>> In general 'auto' is a poor choice for both meanings. 'auto' is obviously
>>>> shorthand for automatic, but automatic what???
>>>> Walter, given that 'auto' as a keyword is not going to be removed from the
>>>> language, how can one currently declare a type-inferred variable that has
>>>> RAII properties?
>>>>
>>>
>>> Regan Heath penned the solution I thought I'd posted a while back, but maybe I hadn't:
>>>
>>>> class A {}
>>>>
>>>> A a = new A(); //normal
>>>> A a = A(); //destroyed at end of scope
>>>>
>>>> and with auto..
>>>>
>>>> auto a = new A(); //normal
>>>> auto a = A(); //destroyed at end of scope
>>>>
>>>> Simple, elegant, obvious (IMO)
>>>
>>>
>>  Myself I would prefer not to have that.  It creates an ambiguity between  a static opCall on A and the storage attribute.
>
> I think "static opCall" is a hack to begin with. It's basically a workaround for structs not having constructors. For classes, there's no point in having a static opCall if Walter implements the "A()" construct.

I agree.

>> I prefer the storage attribute have it's own keyword.  Perhaps give storage 'auto' and type inference 'var'.  For me, that makes it more obvious, since to my eyes it would be a keyword that I've never seen before and now need to look up in the spec - otherwise it's just a static opCall :(.
>
> I also prefer "var" to "auto" for the type inference. I don't think anybody expects "var" to be dynamically typed. Well, maybe a few. And then there's the "auto" from C++; it might confuse people if its meaning were changed.

I think Don's point about there being a lot of user variables called "var" makes "auto" a safer and IMO just as good choice.

Regan
July 25, 2006
On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright wrote:

> Derek wrote:
>> On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
>> 
>>> And what about double meaning of 'auto'?
>> 
>> In general 'auto' is a poor choice for both meanings. 'auto' is obviously shorthand for automatic, but automatic what???
>> 
>> Walter, given that 'auto' as a keyword is not going to be removed from the language, how can one currently declare a type-inferred variable that has RAII properties?
>> 
> 
> Regan Heath penned the solution I thought I'd posted a while back, but maybe I hadn't:
> 
>> class A {}
>> 
>> A a = new A(); //normal
>> A a = A(); //destroyed at end of scope
>> 
>> and with auto..
>> 
>> auto a = new A(); //normal
>> auto a = A(); //destroyed at end of scope
>> 
>> Simple, elegant, obvious (IMO)

I'm sorry but I'm just not getting it. I just tried this example using v0.163 and it fails to compile. I did ask "how can one *CURRENTLY* declare ...". So I guess one can't do it just now and the example is something yet to be implemented.

If so, it means that the opCall paradigm will be removed from classes. Is that intentional?

And I assume that if the class was declared as ...

  auto class A {}

then every object declared with the class would have to be ..

  A a = A();
or
  auto a = A();

But how does this proposed syntax handle variable-length arrays?

  char[] a = read(filename);

Is 'a' destroyed at end of scope?

It seems to me that the implied 'destroy at end of scope' idea is not a good one. It needs explicit designation to make it clear to readers and coders alike. That must also help compilers in detecting coding mistakes too.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
July 25, 2006
And now if you focus on better class libraries, GUI, real debugger, better documentation, samples and  even an IDE for D \or to put it with three letters - SDK\. That would be the best for the language, the technology and the users.

Why not make this SDK Open Source with a comitee of volunteers and develop it as fast as possible? \Just what Project Mono does?\

Good luck!
July 25, 2006
On Tue, 25 Jul 2006 10:31:53 +0200, Don Clugston wrote:


> Nooooooooo!!!!
> Am I the only person who has hundreds of local variables called 'var'?
> (mostly variants in Win32 code).

LOL! You deserve the pain then for choosing such a lame identifier!

> A quick google search for 'var cpp' showed a million hits, a fair chunk of them are local variables in C++ code. It's a very popular variable name.


Oh my Bob! Doesn't anyone go to programming 101 anymore? Why make life hard for yourself by picking identifier names that are likely to clash with keywords *and* that don't help code readers.

Rule#23: Dealing with Identifier Names.
[a] Ensure your identifiers are not valid English words.
[b] Ensure your identifiers either contain a mix of UPPER and
    lowercase characters or contain an underscore or both.
[c] Ensure your identifiers never contain digits.
[d] Ensure your identifiers have at least three (3) characters.
 - Exceptions -
 [e] Single character identifiers, which should always be lowercase.
 [f] Method names can be valid words, but must have mixed case.
 [g] Anything your supervisor signs off on.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
July 25, 2006
Derek skrev:
> On Tue, 25 Jul 2006 00:53:02 -0700, Walter Bright wrote:
> 
>> Derek wrote:
>>> On Mon, 24 Jul 2006 00:33:23 +0000 (UTC), Andrei Khropov wrote:
>>>
>>>> And what about double meaning of 'auto'?
>>> In general 'auto' is a poor choice for both meanings. 'auto' is obviously
>>> shorthand for automatic, but automatic what??? 
>>>
>>> Walter, given that 'auto' as a keyword is not going to be removed from the
>>> language, how can one currently declare a type-inferred variable that has
>>> RAII properties?
>>>
>> Regan Heath penned the solution I thought I'd posted a while back, but maybe I hadn't:
>>
>>> class A {}
>>>
>>> A a = new A(); //normal
>>> A a = A(); //destroyed at end of scope
>>>
>>> and with auto..
>>>
>>> auto a = new A(); //normal
>>> auto a = A(); //destroyed at end of scope
>>>
>>> Simple, elegant, obvious (IMO)
> 
> I'm sorry but I'm just not getting it. I just tried this example using
> v0.163 and it fails to compile. I did ask "how can one *CURRENTLY* declare
> ...". So I guess one can't do it just now and the example is something yet
> to be implemented. 
> 
> If so, it means that the opCall paradigm will be removed from classes. Is
> that intentional?

Walter said: "I'm hard pressed to see the point of them for classes anyway."

(http://www.digitalmars.com/d/archives/digitalmars/D/announce/1727.html)

> 
> And I assume that if the class was declared as ...
> 
>   auto class A {}
> 
> then every object declared with the class would have to be ..
> 
>   A a = A();
> or
>   auto a = A();

I would assume so too.

> But how does this proposed syntax handle variable-length arrays?
> 
>   char[] a = read(filename);

I didn't even know that it is possible to make raii-dynamic arrays. :)

> Is 'a' destroyed at end of scope?

I'd say, definitely not in the above case. It seems the proposed change would remove the ability to declare raii dynamic arrays. The workaround would be:

char[] t = read(filename);
scope(exit) delete t;

> It seems to me that the implied 'destroy at end of scope' idea is not a
> good one. It needs explicit designation to make it clear to readers and
> coders alike. That must also help compilers in detecting coding mistakes
> too.

I'm vaguely agreeing. :) Something a bit more explicit would make the code clearer.

/Oskar
July 25, 2006
Derek wrote:

> If so, it means that the opCall paradigm will be removed from classes. Is that intentional?
> 
> And I assume that if the class was declared as ...
> 
>   auto class A {}
> 
> then every object declared with the class would have to be ..
> 
>   A a = A();
> or
>   auto a = A();
> 
> But how does this proposed syntax handle variable-length arrays?
> 
>   char[] a = read(filename);
> 
> Is 'a' destroyed at end of scope?
> 
> It seems to me that the implied 'destroy at end of scope' idea is not a good one. It needs explicit designation to make it clear to readers and coders alike. That must also help compilers in detecting coding mistakes too.

Yes, good point. I agree.

-- 
AKhropov