View mode: basic / threaded / horizontal-split · Log in · Help
July 25, 2006
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
Re: Is D 0.163 D 1.0?
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
4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home