Bill Baxter wrote:

> "scope" seems a pretty popular suggestion.
> I find it not so bad myself, but I would prefer "scoped" because it's less
> ambiguious.  "scope" makes sense if you think of scope as a verb (scope this
> variable), but just seeing it outside of a sentence it looks like a noun
> (this variable is a scope -- huh?), simply because 'scope' isn't used as a
> verb very often in English.
> 
> 'scoped' is clearly an adjective, as in 'this variable is scoped'.

Yes I also thought of 'scoped'. Sounds like a good idea to me. But I can live with 'scope' or 'var' as well.

I don't like the original proposal

'auto x = ClassName(...)' // type inference, new object, RAII

because sometimes it is hard to distinguish between ClassName (i.e. new object
is created) and FunctionName (it's returned)

With 'scoped' it's clear:

1) auto a = new A();      // type inference, new object, no RAII
2) scoped a = new A();    // type inference, new object, RAII
3) auto a = SomeFunc();   // type inference, object returned from func, no RAII
4) scoped a = SomeFunc(); // type inference, object returned from func, RAII

and of course longer form should be also possible:

'scoped A a = new A();' // RAII, no type inference

> And being
> an adjective puts it in good company with most of the other storage classes
> which are also adjectives: (abstract, auto(matic), const(ant), deprecated,
> extern(al), final, static, synchronized).
> The only non-adjective storage
> class is 'override'.  I have no idea why it's not "overridden".

I think because 'overridden' is too long to type.
I also think "lock(x)" could be better than "synchronized(x)" for the same
reason.

-- 
AKhropov

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.

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


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

Bill Baxter wrote:
> Which is good, since automatic type deduction is basically a typing saving feature to begin with.

No, it's way way more than that. Auto type deduction gets us much closer to the goal of the type of something only needs to be specified once, and then anything that manipulates it infers the right type. This makes code much more robust.

For example,

	auto len = foo.length;

What is the type of foo.length? Is it an int? uint? size_t? class Abc? Without type inference, I'd have to go look it up. With type inference, I know I've got the *correct* type for i automatically.

Now, suppose I change the type of foo.length. I've got to go through and check *every* use of it to get the types of the i's updated. I'll inevitably miss one and thereby have a bug.

With automatic type inference, I'm done before I start, and it's done correctly. The fewer types one has to specify, the better, and note that none of the advantages of static typechecking are lost, either.

Bill Baxter wrote:
> Additionally I keep getting bitten by things like
>     int i;
>     for (i=1; i<10; i++) {
>     }
>     ...
>     foreach(i,elem; elements) {
>        if (...) break;
>     }
>     writefln("last i was", i)
> 
> Which using 'foreach-is-like-for' mentality seems perfectly natural but causes the compiler to complain.

I know it's a little different, but it's so convenient. Also, the no-shadowing rule helps flush out errors at compile time before one gets bitten.

Walter Bright wrote:

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

Well, 'var' is used in C# 3.0 for this purpose (which is obviously a C-family
language and a popular one)
 And it's also used in JavaScript and  Scala
(which have mostly C-family look and feel)
So I think this isn't a serious concern.

And as you can see from this and other threads most people here are happy with it except those who seldom use it for variable naming.

> 
> ("let" is far worse, as it gives the impression that D is some sort of new
> Basic language.)

Forget about Basic, 'let' is used in ML that pioneered the concept of type inference!

And there is also 'def' (from define)
(used in Nemerle for this purpose, in many languages indicates function
definition).

But I'd like to see it short (3-4 characters) otherwise typing 'int' would be
simpler :).

-- 
AKhropov

On Sun, 12 Nov 2006 08:28:51 -0500, Andrey Khropov <andkhropov_nosp@m_mtu-net.ru> wrote:

> Walter Bright wrote:
>
>> And that's why I've avoided using "var".
>
> Well, 'var' is used in C# 3.0 for this purpose (which is obviously a C-family
> language and a popular one)
>  And it's also used in JavaScript and  Scala
> (which have mostly C-family look and feel)
> So I think this isn't a serious concern.
>
> And as you can see from this and other threads most people here are happy with
> it except those who seldom use it for variable naming.
>

I don't like "var" because it reminds me of a cheap script like JavaScript, but I'm not that against it.

Chris Miller escribió:
> On Sun, 12 Nov 2006 08:28:51 -0500, Andrey Khropov <andkhropov_nosp@m_mtu-net.ru> wrote:
> 
>> Walter Bright wrote:
>>
>>> And that's why I've avoided using "var".
>>
>> Well, 'var' is used in C# 3.0 for this purpose (which is obviously a C-family
>> language and a popular one)
>>  And it's also used in JavaScript and  Scala
>> (which have mostly C-family look and feel)
>> So I think this isn't a serious concern.
>>
>> And as you can see from this and other threads most people here are happy with
>> it except those who seldom use it for variable naming.
>>
> 
> I don't like "var" because it reminds me of a cheap script like JavaScript, but I'm not that against it.

So change "var" into "infer", as others sugested, if the only concern is the name of the keyword. :-)

infer x = 2;
infer y = new Foo();

I believe it's the most clear syntax:
- "auto" -> automatic what?
- "var" -> I know it's a variable, so...?
- "infer" -> Ah! It's infering the type...

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

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

Ary Manzana wrote:

> So change "var" into "infer", as others sugested, if the only concern is the name of the keyword. :-)
> 
> infer x = 2;
> infer y = new Foo();

Khm, 5 characters for such a common keyword is too long (may be 'inf', but inf
is a common word for infinity)
And 'infer' also looks very close to 'inferior'.

-- 
AKhropov

Andrey Khropov escribió:
> Ary Manzana wrote:
> 
>> So change "var" into "infer", as others sugested, if the only concern is the
>> name of the keyword. :-)
>>
>> infer x = 2;
>> infer y = new Foo();
> 
> Khm, 5 characters for such a common keyword is too long (may be 'inf', but inf
> is a common word for infinity)

What?!

I'm not going to time it, but typing "inf", "var", "auto", "infer", "while", "foreach", etc., should take you about the same time. I don't think a char or two make the difference (I don't know wether your concern is typing it or if the source code will have 5 o 6 bytes more).

Second, I don't know if it such a common keyword. Look at all these keywords: "while", "static", "class", "interface", "foreach", "override", "alias", "import", "module", "assert" (very, very common!), "continue", "break", and the list goes on (let's not talk about "foreach_reverse" :-P). I think clarity instead of "let's save letters to make our language more compact... but less clear" is better. "interface" has 9 letters, why now change it to "inter"? It's a very common keyword, and we'll save some bytes there.

> And 'infer' also looks very close to 'inferior'.

But "infer" *is* "infer", it's not "inferior". And people would know that "infer" is what it is (at least it's more obvious than "auto").

Just my opinion...