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.

I add my vote to the many others who want 'scope' for all cases of RAII.

Walter Bright escribió:
> 
> My problem with "var" is the history of the keyword. Back in the olden days, there were two main camps of programmers - the Pascal people, and the C people. Each camp looked with disdain upon the other as "not getting it". The Pascal crowd progressed to Modula 2, Object Pascal, and eventually Delphi. The C family progressed to C++, Java, and D. There didn't seem to be much voluntary mixing up, people would switch camps only under duress.
> 
> So I have a real (possibly outdated) concern that "var" appearing in D will make the language distasteful to the C crowd. The appearance of a language matters a lot, it's like the clothes one wears that identifies one (consciously or not) as being with a particular group.
> 
> And that's why I've avoided using "var".
> 
> ("let" is far worse, as it gives the impression that D is some sort of new Basic language.)
> 
> 

I don't think they're valid concerns (meaning they're subjective, not everyone will have those ideas), but I think we (the D community) just want a way to clearly differentiate both meanings of auto. So, choose any two words: auto/scope, var/auto, def/scoped, foo/bar, and let's move on.

Also keep in mind that your option #5 (auto c = Class()) doesn't seem to be a popular proposal (based on what has been said in the ng).

-- 
Carlos Santander Bernal

Dave wrote:
> 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. 
Not so, 'auto' *never* means 'type inference'. It's the absence of a type that means type inference. But the usage of auto to mean both 'raii' and 'local variable storage class' is really confusing people.

> 'auto' just seems too much like a deprecated artifact of C.

Agreed, but I don't know of anything better.

const infer x = 3.5;
static infer x = 4.5L;

are too wordy.

> 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 Sun, 12 Nov 2006 08:50:51 +0200, Daniel Keep <daniel.keep.lists@gmail.com> wrote:
[snip]
> On a related note, I don't suppose I could ask you to take a second look
> at my old proposal on allowing auto objects to be returned from
> functions, could I? :P  It is one of the very, very few things I'd still
> like to see in D 1.0.
>
> <http://www.digitalmars.com/d/archives/digitalmars/D/38329.html>
>
> 	-- Daniel
>

I especially liked the the 'auto members'. It's not uncommon that member variables of an object are only used by the object (they are binded together forming a compact entity), and they should be destroyed with the object. Currently you have to explicitly delete the member variables in the object's destructor, right? Sometimes I miss value types. They are created and destroyed with the parent object automatically.

And basically you're trying to create value types here? Objects are destroyed at the end of scopes, and they are cloned/dublicated in assingments. In reference counting the objects themselves are cloned, the data is refenced. Well, actually the reference counts must be updated in assignments. So, what we actually need for reference counting is an ability to override the assignment operators.

On Sat, 11 Nov 2006 20:48:00 +0200, 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:
>
> 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.

I, too, think that we should have new keywords for type inference and RAII.

I like 'var' for type inference. For RAII, I guess 'scope' is ok, even if it's a bit 'funny'; 'scoped' would be better. 'local' would be nice too: it's adjective.

For example (I use 'scoped' here):

  var a = 1;
  var int b = 2;

  var c = new Class;
  scoped d = new Class;      //RAII
  scoped var e = new Class;  //RAII


What if a RAII keyword could be used with 'new' too?

  var a = new scoped Class;  //RAII
  var b = scoped Class;      //RAII


Well, I think 'auto' would be useful with 'RAII classes' and 'RAII member variables', if they are implemented in the future. (If a better word cannot be invented, of course.) E.g.

  class Foo {
    auto Bar b;  //'b' is automatically destroyed with 'Foo'
    }

Kristian Kilpi wrote:
> On Sun, 12 Nov 2006 12:24:35 +0200, Walter Bright <newshound@digitalmars.com> wrote:
>> Sean Kelly wrote:
>>> 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".
>>>  As Don explained to me, 'auto' is a storage class in D and in C along with 'const' and 'static', so type inference doesn't occur because 'auto' is present so much as because a type is omitted.  The presence of 'auto' merely serves to indicate that the statement is a declaration (since 'auto' is the default storage class and therefore otherwise optional).  Type inference occurs with the other storage classes as well.  I think this is an important distinction because it seems to be a common misconception that 'auto' means 'infer the type of this expression' and that a specific label is necessary for this feature.
>>
>> True. Consider that type inference works in these cases:
>>
>>     static a = 3;    // a is an int
>>     const b = '3';    // b is a char
>>
>> So auto doesn't actually ever mean "infer the type", it's just needed because one of the other storage class keywords isn't there.
> 
> So according to this logic, auto should always mean RAII?
> E.g.
> 
>   auto c = new Class;  //RAII

Storage class specifiers are really only intended to indicate how the labeled variable (in this case a class reference/pointer) is stored. 'const' places the variable in a special read-only area, 'static' places the variable in static memory, and 'auto' places the variable on the stack.  For RAII to apply, the behavior of class references would probably need to change so the referenced value is destroyed when the reference goes out of scope, and this would effectively eliminate any means of returning objects from functions since D objects cannot be passed by value.

> If not, then one could argue that
> 
>   static a = 3;
> 
> declares non-static variable, i.e. the static keyword is used for type inference only (whenever the type is omited).

Not at all.  This declares a type-inferred static variable.  The type inference occurs because a type is omitted, but the storage class specifier still applies.  The same goes for 'const'.


Sean

On Sun, 12 Nov 2006 19:02:18 +0200, Sean Kelly <sean@f4.ca> wrote:

> Kristian Kilpi wrote:
>> On Sun, 12 Nov 2006 12:24:35 +0200, Walter Bright <newshound@digitalmars.com> wrote:
>>> Sean Kelly wrote:
>>>> 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".
>>>>  As Don explained to me, 'auto' is a storage class in D and in C along with 'const' and 'static', so type inference doesn't occur because 'auto' is present so much as because a type is omitted.  The presence of 'auto' merely serves to indicate that the statement is a declaration (since 'auto' is the default storage class and therefore otherwise optional).  Type inference occurs with the other storage classes as well.  I think this is an important distinction because it seems to be a common misconception that 'auto' means 'infer the type of this expression' and that a specific label is necessary for this feature.
>>>
>>> True. Consider that type inference works in these cases:
>>>
>>>     static a = 3;    // a is an int
>>>     const b = '3';    // b is a char
>>>
>>> So auto doesn't actually ever mean "infer the type", it's just needed because one of the other storage class keywords isn't there.
>>  So according to this logic, auto should always mean RAII?
>> E.g.
>>    auto c = new Class;  //RAII
>
> Storage class specifiers are really only intended to indicate how the labeled variable (in this case a class reference/pointer) is stored. 'const' places the variable in a special read-only area, 'static' places the variable in static memory, and 'auto' places the variable on the stack.  For RAII to apply, the behavior of class references would probably need to change so the referenced value is destroyed when the reference goes out of scope, and this would effectively eliminate any means of returning objects from functions since D objects cannot be passed by value.

So 'auto' in "auto c = new Class;" means that 'c' (the variable, not the object referenced by it) is stored in the stack? (That's of course the case whenever 'static' is not used.) 'auto' has nothing to do when RAII should be applied to the referenced object (in princible)?

>
>> If not, then one could argue that
>>    static a = 3;
>>  declares non-static variable, i.e. the static keyword is used for type inference only (whenever the type is omited).
>
> Not at all.  This declares a type-inferred static variable.  The type inference occurs because a type is omitted, but the storage class specifier still applies.  The same goes for 'const'.
>
>
> Sean

Yes, I was trying to point out that 'auto' works inlogically when compared to other store classes. :)

1a) auto c = new Class();              //non-RAII
2a) auto Class c = new Class();        //RAII
3a) auto c = some_expression();        //non-RAII
4a) auto Class c = some_expression();  //RAII

Now, lets replace 'auto' with 'static':

1b) static c = new Class();              //static
2b) static Class c = new Class();        //static
3b) static c = some_expression();        //static
4b) static Class c = some_expression();  //static

Because the cases 1b and 3b currently create static variables, so should the cases 1a and 3a create RAII objects.

(But because auto does not actually mean RAII, well, it's still confusing.)

Kristian Kilpi wrote:
> On Sun, 12 Nov 2006 19:02:18 +0200, Sean Kelly <sean@f4.ca> wrote:
> 
>> Kristian Kilpi wrote:
>>> On Sun, 12 Nov 2006 12:24:35 +0200, Walter Bright <newshound@digitalmars.com> wrote:
>>>> Sean Kelly wrote:
>>>>> 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".
>>>>>  As Don explained to me, 'auto' is a storage class in D and in C along with 'const' and 'static', so type inference doesn't occur because 'auto' is present so much as because a type is omitted.  The presence of 'auto' merely serves to indicate that the statement is a declaration (since 'auto' is the default storage class and therefore otherwise optional).  Type inference occurs with the other storage classes as well.  I think this is an important distinction because it seems to be a common misconception that 'auto' means 'infer the type of this expression' and that a specific label is necessary for this feature.
>>>>
>>>> True. Consider that type inference works in these cases:
>>>>
>>>>     static a = 3;    // a is an int
>>>>     const b = '3';    // b is a char
>>>>
>>>> So auto doesn't actually ever mean "infer the type", it's just needed because one of the other storage class keywords isn't there.
>>>  So according to this logic, auto should always mean RAII?
>>> E.g.
>>>    auto c = new Class;  //RAII
>>
>> Storage class specifiers are really only intended to indicate how the labeled variable (in this case a class reference/pointer) is stored. 'const' places the variable in a special read-only area, 'static' places the variable in static memory, and 'auto' places the variable on the stack.  For RAII to apply, the behavior of class references would probably need to change so the referenced value is destroyed when the reference goes out of scope, and this would effectively eliminate any means of returning objects from functions since D objects cannot be passed by value.
> 
> So 'auto' in "auto c = new Class;" means that 'c' (the variable, not the object referenced by it) is stored in the stack? (That's of course the case whenever 'static' is not used.) 'auto' has nothing to do when RAII should be applied to the referenced object (in princible)?

Yes.

    auto MyClass c = new MyClass;

currently overloads the meaning of 'auto' to specify that the object referenced by 'c' when 'c' goes out of scope will be deleted.  Here, 'auto' isn't really a storage class specifier, although it looks like one.

>>> If not, then one could argue that
>>>    static a = 3;
>>>  declares non-static variable, i.e. the static keyword is used for type inference only (whenever the type is omited).
>>
>> Not at all.  This declares a type-inferred static variable.  The type inference occurs because a type is omitted, but the storage class specifier still applies.  The same goes for 'const'.
> 
> Yes, I was trying to point out that 'auto' works inlogically when compared to other store classes. :)
> 
> 1a) auto c = new Class();              //non-RAII
> 2a) auto Class c = new Class();        //RAII
> 3a) auto c = some_expression();        //non-RAII
> 4a) auto Class c = some_expression();  //RAII

Agreed.

> Now, lets replace 'auto' with 'static':
> 
> 1b) static c = new Class();              //static
> 2b) static Class c = new Class();        //static
> 3b) static c = some_expression();        //static
> 4b) static Class c = some_expression();  //static
> 
> Because the cases 1b and 3b currently create static variables, so should the cases 1a and 3a create RAII objects.
> 
> (But because auto does not actually mean RAII, well, it's still confusing.)

Yes is is, which is why RAII semantics need to be nailed down before 1.0 in a way that makes sense.


Sean

Walter Bright wrote:
> Lionello Lunesu wrote:
> 
>>> (a) Get rid of 'auto'.
>>
>> I completely agree. The current "auto" can then be tagged as deprecated and removed Jan 1st!
>>
>>> (b) Create a new keyword that is more obviously read as 'type inference'.
>>
>> I like "var".
> 
> My problem with "var" is the history of the keyword. Back in the olden days, there were two main camps of programmers - the Pascal people, and the C people. Each camp looked with disdain upon the other as "not getting it". The Pascal crowd progressed to Modula 2, Object Pascal, and eventually Delphi. The C family progressed to C++, Java, and D. There didn't seem to be much voluntary mixing up, people would switch camps only under duress.

These are big things, no denying it.

> So I have a real (possibly outdated) concern that "var" appearing in D will make the language distasteful to the C crowd. The appearance of a language matters a lot, it's like the clothes one wears that identifies one (consciously or not) as being with a particular group.
> 
> And that's why I've avoided using "var".
> 
> ("let" is far worse, as it gives the impression that D is some sort of new Basic language.)

Good point. "let" is a lot worse than var. And still, I used "let" a lot in Scheme. Go figure.

But then, the very concept of type inference is not exactly a C concept, and hence it's sort of OK to then have a, er, unforgettable word for it, right? Things have also changed: in the old days it was pretty much Pascal vs C, but today everybody is fluent in a half dozen other languages as well, some of which do use "var".

But the biggest thing of all with "var" is, it's only three letters! It's certainly easier to type than "let_the_compiler_freely_infer_the_type_here".

<joke>How about "we"? Shorter still. Oh, what does it stand for? Well obviously it's whatever. Can't get much more appropriate.</joke>

>>> (c) Create a new keyword that is more obviously read as 'resource
>>> destruction at end of scope'.
>>
>> I like "scope"

I also am voting the majority, two different words - neither of which are auto, 'var' for inference ( as is used allot in modern C family
languages ) , and 'scope' for RAII.

> 5) auto c = Class();

Oh the horror!!!

Charlie

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.