July 25, 2006
On Tue, 25 Jul 2006 21:39:29 +1000, Derek <derek@psyc.ward> wrote:
> 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.

It's not yet implemented.

> I did ask "how can one *CURRENTLY* declare ...".

I was replying to Shaun when I put forward the syntax above, not you ;)

> So I guess one can't do it just now and the example is something yet to be implemented.

Correct.

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

My opinion is that _static_ opCall is of very limited use for classes. I won't miss it. Heck, my vote is for struct constructors and the removal of static opCall entirely.

> 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();
>   auto a = A();

Yes. I assume it would be an error to use 'new' on an 'auto class', but, I don't really like the idea of 'auto class'es at all.

> But how does this proposed syntax handle variable-length arrays?
>
>   char[] a = read(filename);
>
> Is 'a' destroyed at end of scope?

No.

It's my understanding that the purpose of 'auto'(destruction) is to guarantee a call to a class destructor, not to delete memory. After all, the GC will delete the array (assuming it's unreferenced) when it next does a collect. I think it should be illegal to apply 'auto'(destruction) to anything other than a class reference.

Regan
July 25, 2006
Derek wrote:
> 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!

Yes, it's as lame as 'x', and deliberately so.
It's lamer as a keyword, IMHO. It's not an English word. 'auto' has been widely promoted for exactly that purpose in C++, and 'var' had a completely different meaning in Pascal. I cannot understand the attraction to 'var'.

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

Because meaningless local variables/parameters should not have meaningful names; otherwise, you're being _unhelpful_ to code readers!
The most common meaningless names I use are 'x', 'y', 'n', 'p', 'q', 'val' and 'var', and 'arr'.

I guess I never went to programming 101.

> 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.
The main time I do this is with constructions of the form...

template (P1, P2, P3, P4)
void func(P1 p1, P2 p2, P3 p3, P4 p4)

(where you'd like them to be an array, but the language doesn't allow it). How would you do it?

> [d] Ensure your identifiers have at least three (3) characters.

Never heard that one before. What's the reason?

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

Fine, but I think it's reasonable to assume that any new keyword will be either an English word, very obscure, or most likely both. Given that the number of new keywords will be *extremely* small, I don't think it makes much sense to have the risk of a collision be a major driver of naming convention. I really don't like your rule [b], when applied to local variables and parameter names, I think it reduces legibility, but I think it's reasonable for method names.
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) 

Yup, you had :-)

Assuming this happens, is there any chance it could be a valid syntax for initializing concrete types as well?  Personally, I find it quite useful that C++ uses the same syntax for all types, be they user-defined or not, as it makes for simpler template code.


Sean
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.
> 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 :(.

By the way, I'd suggested an alternate syntax that admittedly uses a new keyword:

A a = local A();

(or I suppose)

A a = auto A();

I think it's more appropriate to attach the keyword to the initializer rather than the declaration since the reference is just a reference either way.


Sean
July 25, 2006
On Tue, 25 Jul 2006 15:20:13 +0200, Don Clugston wrote:

> Derek wrote:

>> Rule#23: Dealing with Identifier Names.

LOL... It was a joke, sorry. I just scribbled down some junk without thinking about it too deeply. I'm not pushing a barrow here.

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"
July 25, 2006
Don Clugston wrote:

> It's lamer as a keyword, IMHO. It's not an English word.

'var' is short for 'variable' like 'int' is short for 'integer'


> 'auto' has been
> widely promoted for exactly that purpose in C++

Yes, but in C++ only. And don't forget that in C++ there is already a (redundant but still valid) keyword 'auto' that means scoped variables like it was in D before type inference:

This is a quote from "Stroustrup. The C++ programming language, 3rd ed":

--------------------------------------------------------------------------------

Automatic memory, in which function arguments and local variables are
allocated. Each entry into a function or a block gets its own copy. This kind
of memory is automatically created and destroyed; hence the name automatic
memory. Automatic memory is also said ‘‘to be on the stack.’’ If you absolutely
must be explicit about this, C++ provides the redundant keyword *auto*.
--------------------------------------------------------------------------------

So it would be also confusing in C++ if they accept this proposal.

> I cannot understand the attraction to 'var'.

Because it is meaningful (short for 'variable') and already used in several
languages (JavaScript, C# 3.0, Scala...) for this purpose.


P.S. And I like 'val' (from 'value') in Scala that means immutable variable (in
fact just named constant or value), compare:

--------------------
Scala: val i = 1;
--------------------
C++: const int i = 1;
--------------------

It's short and readable (IMHO).

-- 
AKhropov
July 25, 2006
Don Clugston wrote:

> It's lamer as a keyword, IMHO. It's not an English word.

'var' is short for 'variable' like 'int' is short for 'integer'


> 'auto' has been
> widely promoted for exactly that purpose in C++

Yes, but in C++ only. And don't forget that in C++ there is already a (redundant but still valid) keyword 'auto' that means scoped variables like it was in D before type inference:

This is a quote from "Stroustrup. The C++ programming language, 3rd ed":

--------------------------------------------------------------------------------

Automatic memory, in which function arguments and local variables are
allocated. Each entry into a function or a block gets its own copy. This kind
of memory is automatically created and destroyed; hence the name automatic
memory. Automatic memory is also said ‘‘to be on the stack.’’ If you absolutely
must be explicit about this, C++ provides the redundant keyword *auto*.
--------------------------------------------------------------------------------

So it would be also confusing in C++ if they accept this proposal.

> I cannot understand the attraction to 'var'.

Because it is meaningful (short for 'variable') and already used in several
languages (JavaScript, C# 3.0, Scala...) for this purpose.


P.S. And I like 'val' (from 'value') in Scala that means immutable variable (in
fact just named constant or value), compare:

--------------------
Scala: val i = 1;
--------------------
C++: const int i = 1;
--------------------

It's short and readable (IMHO).

-- 
AKhropov
July 25, 2006
Don Clugston wrote:
> 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.

Actually I do feel your pain, but I still vote for it.  Waaay back in the day I used to do a lot of LambdaMOO server hacking, and therein I discovered my first Var struct.  (That'd be about 1996 I think it was.)  Now, ten years later, I am working on BovisMOO... and I'm still using a Var struct (albeit a much cleaner one), and plenty of temporary Var's named, yes, 'var.'

But I can always just rename them to 'tmp', or something else.  (Actually a lot of them would probably get renamed 'result' since that's what they generally are.)

-- Chris Nicholson-Sauls
July 25, 2006
Andrei Khropov wrote:
> P.S. And I like 'val' (from 'value') in Scala that means immutable variable (in
> fact just named constant or value), compare:
> 
> --------------------
> Scala: val i = 1;
> --------------------
> C++: const int i = 1;
> --------------------
> 
> It's short and readable (IMHO).
> 

D: const i = 1;

Its like a compromise.  ;)

-- Chris Nicholson-Sauls
July 25, 2006
Walter Bright wrote:
> I think the title says it all.

DMD 0.163 (the compiler its self)
	No

D's feature set as implemented and/or documented with DMD 0.163
	Yes (reluctantly)

D's specs as documented with 0.163
	No

Phobos 0.163 (and all the other libs)
	No

We can go with the features we have, some of them need to be tweaked a bit though.

The spec it's self needs some editing/elaboration/etc.

The libs _may_ need a total rewrite.

Also DMD will need few months of bug work after the D spec v1.0 is cut into a stone tablet. (But those bug fixes could get numbered 1.0.x for all I care.)