The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:

class Class { }

1) auto c = new Class();
2) auto Class c = new Class();
3) auto c = some_expression();
4) auto Class c = some_expression();

The ambiguity can be resolved by saying that if auto is used for type inference, i.e. cases (1) and (3), then it does not mean RAII. If it is not used for type inference, i.e. cases (2) and (4), then it does mean RAII.

In the future, I'd like the following to work:

5) auto c = Class();

which would mean type inference *and* RAII.

Walter Bright escribió:
> The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:
> 
> class Class { }
> 
> 1) auto c = new Class();
> 2) auto Class c = new Class();
> 3) auto c = some_expression();
> 4) auto Class c = some_expression();
> 
> The ambiguity can be resolved by saying that if auto is used for type inference, i.e. cases (1) and (3), then it does not mean RAII. If it is not used for type inference, i.e. cases (2) and (4), then it does mean RAII.
> 
> In the future, I'd like the following to work:
> 
> 5) auto c = Class();
> 
> which would mean type inference *and* RAII.

Since this has been talked a lot already, I'll only say: auto for RAII, and something else (eg: var) for type inference.
IMHO.

-- 
Carlos Santander Bernal

On Sat, 11 Nov 2006 13:48:00 -0500, Walter Bright <newshound@digitalmars.com> wrote:

> The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:
>

Choosing from your list I guess "auto" for auto destruction and "infer" for auto type deduction.

However, I tend to prefer "scope" (without parentheses following) for auto destruction, which frees up "auto" for auto type deduction:

   scope Object o = new Object(); // Destructed at end of scope.
   scope auto q = new Foo(); // Auto type deduction and end-of-scope destruction.

Chris Miller wrote:

> On Sat, 11 Nov 2006 13:48:00 -0500, Walter Bright <newshound@digitalmars.com> wrote:
> 
>> The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:
>>
> 
> Choosing from your list I guess "auto" for auto destruction and "infer" for auto type deduction.
> 
> However, I tend to prefer "scope" (without parentheses following) for auto destruction, which frees up "auto" for auto type deduction:
> 
>     scope Object o = new Object(); // Destructed at end of scope.
>     scope auto q = new Foo(); // Auto type deduction and end-of-scope
> destruction.

Considering that scope already exists as a keyword, I find this an excellent suggestion that is also very much clearer in meaning (I find auto to miss the target for both cases really :P ).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Lars Ivar Igesund wrote:
> Chris Miller wrote:
> 
> 
>>On Sat, 11 Nov 2006 13:48:00 -0500, Walter Bright
>><newshound@digitalmars.com> wrote:
>>
>>
>>>The auto storage class currently is a little fuzzy in meaning, it can
>>>mean "infer the type" and/or "destruct at end of scope". The latter only
>>>has meaning for class objects, so let's look at the syntax. There are 4
>>>cases:
>>>
>>
>>Choosing from your list I guess "auto" for auto destruction and "infer"
>>for auto type deduction.
>>
>>However, I tend to prefer "scope" (without parentheses following) for auto
>>destruction, which frees up "auto" for auto type deduction:
>>
>>    scope Object o = new Object(); // Destructed at end of scope.
>>    scope auto q = new Foo(); // Auto type deduction and end-of-scope
>>destruction.
> 
> 
> Considering that scope already exists as a keyword, I find this an excellent
> suggestion that is also very much clearer in meaning (I find auto to miss
> the target for both cases really :P ).
> 

I've already said it before, but it bears repeating yet again.  I also prefer 'scope' for this.  Although 'infer' wouldn't be bad -- but please, please, please, not 'var'!  It smells too much like a scripting language construct, and besides, my Bovis code is overflowing with actual variables named var.  (Probably because of the BVar struct that it passes most values around as.  Go figure.)

-- Chris Nicholson-Sauls

Carlos Santander wrote:
> Walter Bright escribió:
> 
>> The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:
>>
> Since this has been talked a lot already, I'll only say: auto for RAII, and something else (eg: var) for type inference.
> IMHO.

I agree.  Even if "everybody else is doing it", I think auto is a poor choice for an automatic type deduction indicator. I'd be much happier with any of

   var foo = expression;
   val foo = expression;
   def foo = expression;
   let foo = expression;

As an added bonus all of those are one character less than the current auto.  Which is good, since automatic type deduction is basically a typing saving feature to begin with.  To me 'auto' in front of an identifier looks like it's saying this is an "automatic variable", which, going back to the original K&R book, has always meant a local, scoped variable.  It sounds like it's going to do something at run time.

For anyone who complains "I'm using that as a variable name already", I'll write you a script to fix your files.  Here you go

   perl -pi -e 's/(\W)(val)(\W)/${1}${2}_${3}/g' *.d

Or if you may already have things name val_ in your code

   perl -pi -e 's/(\W)(val_*)(\W)/${1}${2}_${3}/g' *.d

--bb

== Quote from Chris Miller (chris@dprogramming.com)'s article
>     scope Object o =3D new Object(); // Destructed at end of scope.

Excellent suggestion! I would also like to see scoped classes like:

scope class AutoDestroy {
}

AutoDestroy createAutoDestroyObject() {
    return new AutoDestroy();
}

void test() {
    AutoDestroy d = createAutoDestroyObject();
    // d will be destroyed here
}

This way, I can use classes with deterministic destruction the same way as other classes. Scoped classes should also be able to be returned from functions, passed as parameters, or be fields of other scoped classes. It is up to programmer (and maybe, later, compiler escape analysis) to make sure variable doesn't escape scope.

This is the #1 feature on my wish list and I really, really need it. Absence of good RAII is a major pain (auto classes are way too restricted).

Chris Miller wrote:
> On Sat, 11 Nov 2006 13:48:00 -0500, Walter Bright <newshound@digitalmars.com> wrote:
> 
>> The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:
>>
> 
> Choosing from your list I guess "auto" for auto destruction and "infer" for auto type deduction.
> 
> However, I tend to prefer "scope" (without parentheses following) for auto destruction, which frees up "auto" for auto type deduction:
> 
>    scope Object o = new Object(); // Destructed at end of scope.
>    scope auto q = new Foo(); // Auto type deduction and end-of-scope destruction.

scope has my vote, its elegant, as raii is functionally similar to the scope(x) construct.

Kyle Furlong wrote:
> Chris Miller wrote:
>> On Sat, 11 Nov 2006 13:48:00 -0500, Walter Bright <newshound@digitalmars.com> wrote:
>>
>>> The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:
>>>
>>
>> Choosing from your list I guess "auto" for auto destruction and "infer" for auto type deduction.
>>
>> However, I tend to prefer "scope" (without parentheses following) for auto destruction, which frees up "auto" for auto type deduction:
>>
>>    scope Object o = new Object(); // Destructed at end of scope.
>>    scope auto q = new Foo(); // Auto type deduction and end-of-scope destruction.
> 
> scope has my vote, its elegant, as raii is functionally similar to the scope(x) construct.

Vote++.

But Walter specifically (and I think purposefully) left out any mention of new keywords. Nonetheless I'd like to see auto deprecated in favor of 'infer'. 'scope' and 'infer' both describe exactly what they are used for. 'auto' just seems too much like a deprecated artifact of C.

Based on previous discussions though, 'auto' is here to stay one way or the other forever. I sincerely don't understand Walter's infatuation with 'auto', but it is what it is.

On Sat, 11 Nov 2006 10:48:00 -0800, Walter Bright wrote:

> The auto storage class currently is a little fuzzy in meaning, it can mean "infer the type" and/or "destruct at end of scope". The latter only has meaning for class objects, so let's look at the syntax. There are 4 cases:
> 
> class Class { }
> 
> 1) auto c = new Class();
> 2) auto Class c = new Class();
> 3) auto c = some_expression();
> 4) auto Class c = some_expression();
> 
> The ambiguity can be resolved by saying that if auto is used for type inference, i.e. cases (1) and (3), then it does not mean RAII. If it is not used for type inference, i.e. cases (2) and (4), then it does mean RAII.
> 
> In the future, I'd like the following to work:
> 
> 5) auto c = Class();
> 
> which would mean type inference *and* RAII.

Please excuse my bash and amateur crashing in here ... but Walter, for a very intelligent person, why is it that you just don't get it?

Type inference and RAII are two distinct, unrelated and orthogonal concepts. Using one keyword in subtly different syntax permutations to indicate both concepts is just plain stupid.

In each of the suggested permutations above, the code reader and writer will constantly be thinking "now what's the precise syntax again?"  This reminds me of the exact criticism that you have leveled against some C++ constructs, and some syntax changes to D suggested by your supporters. Namely that the subtle differences in syntax variants is a cause of bugs and makes writing code harder - because they are not visually distinct enough for the average person.

Why do we want Type Inference? At least two reason pop into mind; to help write generic code, which means less rewriting/editing of code, and to avoid using long type names (shorter words to type). Thus a short keyword to indicate type inference would be a better idea than using a long word.

Why do we want RAII? So we don't have to also write explicit 'destructor' invocation code and thus reduce the amount of coding required. So again, a short keyword rather than a long keyword would be more beneficial.

However, to use the same keyword for these two unrelated uses is an ugly wart on your language.

Further more 'auto' is ambiguous? Is it 'automatic'-inference, 'automatic'-RAII, 'automatic'-<some_thing_else>?

My plea is ...

(a) Get rid of 'auto'.
(b) Create a new keyword that is more obviously read as 'type inference'.
(c) Create a new keyword that is more obviously read as 'resource
destruction at end of scope'.
(d) Allow any combination of these new keywords on the same declaration
statement.
(e) Allow any combination of these new keywords on declarations at the
module level.

That will make reading and writing D code less costly, and increase the joy in using your wonderful language.

-- 
Derek Parnell