Walter Bright wrote:
> Carlos Santander wrote:
> 
>> 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.
> 
> 
> I think the auto/scope is probably the best idea.
> 
>> 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).
> 
> 
> I'm a bit surprised at that, but the negative reaction to it is pretty clear.

And I'm a bit surprised by your surprise, given that it creates a special case rule for one particular, not-so-common situation, *AND* at the same time breaks static opCall.

--bb

Bill Baxter wrote:
> Walter Bright wrote:
>> Andrey Khropov wrote:
>>
>>> Well, 'var' is used in C# 3.0 for this purpose (which is obviously a C-family
>>> language and a popular one)
>>
>>
>> C# was designed by a Anders Hjelsberg, who wrote Pascal compilers and designed Delphi.
> 
> Good point.  But have you heard *anyone* complain that they don't want to use C# because it's too much like Pascal?

Nope. But I also don't have a billion dollars to spend to convince people to look deeper than a first impression.

Bill Baxter wrote:
> Walter Bright wrote:
>> Carlos Santander wrote:
>>
>>> 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.
>>
>>
>> I think the auto/scope is probably the best idea.
>>
>>> 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).
>>
>>
>> I'm a bit surprised at that, but the negative reaction to it is pretty clear.
> 
> And I'm a bit surprised by your surprise, given that it creates a special case rule for one particular, not-so-common situation, *AND* at the same time breaks static opCall.

What is the special case here?

    int i  = 5;       // scoped int
    int* j = new int; // dynamic int

    MyClass c = MyClass();     // scoped class
    MyClass d = new MyClass(); // dynamic class

The only thing better would be if the ctor syntax applied to concrete types as well.  Then templates could almost be generic in how they dealt with types.

That said, I do appreciate your concern about static opCall.  As a somewhat bizarre suggestion that would break the consistency illustrated above:

    MyClass c = new(scope) MyClass(); // scoped class
    MyClass d = new MyClass;          // dynamic class

I don't really like this, but it would work with the existing placement new syntax and doesn't require any new keywords either.


Sean

Ary Manzana wrote:
> 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...

Wholeheartedly agreed.  I really do hope 'var' doesn't make it in...  I actually use it /quite a lot/ in my code.  Last night, to see what the impact would be, I ran a search through some of my code... and had hundreds of hits for just "var", let alone all the other things with "-var-" in their names because I've assumed it was a safe name.

-- Chris Nicholson-Sauls

Bill Baxter wrote:

> Forget about ML, 'let' is used in Lisp, the granddaddy of all functional programming languages!

Thanks for the enlightment, I'm not that familiar with Lisp.

Anyway I associate Basic with this 'Dim' and 'As' things and not 'let'.

-- 
AKhropov

Sean Kelly wrote:
> Bill Baxter wrote:
>> Walter Bright wrote:
>>> Carlos Santander wrote:
>>>
>>>> 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.
>>>
>>>
>>> I think the auto/scope is probably the best idea.
>>>
>>>> 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).
>>>
>>>
>>> I'm a bit surprised at that, but the negative reaction to it is pretty clear.
>>
>> And I'm a bit surprised by your surprise, given that it creates a special case rule for one particular, not-so-common situation, *AND* at the same time breaks static opCall.
> 
> What is the special case here?
> 
>     int i  = 5;       // scoped int
>     int* j = new int; // dynamic int
> 
>     MyClass c = MyClass();     // scoped class
>     MyClass d = new MyClass(); // dynamic class

That doesn't look particularly consistent to me.
In one case you have int vs int*, the other case you have MyClass for both.

But I could live with it if it weren't for that fact that x = MyClass() already has another meaning in D.

--bb

"Sean Kelly" <sean@f4.ca> wrote in message news:ej87h8$10nk$1@digitaldaemon.com...

> What is the special case here?
>
>     int i  = 5;       // scoped int
>     int* j = new int; // dynamic int
>
>     MyClass c = MyClass();     // scoped class
>     MyClass d = new MyClass(); // dynamic class

My main problem with it (besides not being able to use static opCall, which I do use), is that it's far, far too easy to miss.  The first time Walter proposed this .. "syntax," I didn't know what he was proposing until I looked real hard at the code for a minute or two.  If you _really_ want to make it obvious that it's a RAII class instance, either use a different keyword, or maybe even recycle the C++ way:

MyClass c(params);

Not that I'm entirely supporting that syntax, but the "Class name = new Class()" is such a common idiom that introducing the very-similar-looking "Class name = Class()" will only cause confusion.

Walter Bright wrote:
> Bill Baxter wrote:
>>  From a software maintenance and robustness standpoint I think that cuts both ways.  If I don't know the type then it's easy to do something wrong with it like
>>
>>    auto len = foo.length;
>>    len = -1;  // oops! len is unsigned!  not what I intended!
> 
> If you wrote:
> 
>     int len = foo.length;
> 
> and foo.length was unsigned, isn't that just another sort of bug?

Yeh, I suppose.  On the other hand my specification of a type is a kind of contract that the compiler can check.  Both have their uses, but I'm just saying specifying the type should be the default policy, unless there's a compelling reason not to (i.e. it's obvious from context).

I guess the best maintenance argument for why auto should be used sparingly is that information should be as localized as possible.  It's why C++ gurus say you should declare at point of use whenever possible (rather than using C-style top-of-the-function declarations).  It's also one reason why globals are considered bad, and why creative operator overloading is a bad idea.  All those things can make you have to go searching all over your codebase to figure out the meaning of one little line of code.

--bb

Andrey Khropov wrote:
> 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.

I realized 'scope' is already a keyword.  I think that's why people are gravitating towards that instead of the more natural 'scoped'.

I think the globally optimum solution would be to make the other 'scope' into 'scoped' too.

    scoped(exit) writefln("leaving now");

That reads just fine to me.  Whereas

    scope var = new Class;

looks funny.  Oh well.  Probably hopeless.

--bb

Walter Bright wrote:
> Carlos Santander wrote:
>> 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.
> 
> I think the auto/scope is probably the best idea.

That will have some affect on this:

    int (a) = 3;
    writefln(a);
    int (exit) = 9;
    writefln(exit);

which all is currently ok.  But with scope as a storage class, this:

    scope (exit) ;

would become ambiguious.  Is it an empty scope(exit){} or is it a scoped variable called exit that wasn't initialized?

Not a huge deal, but perhaps a reason to consider using 'scoped' for the storage class instead of reusing the 'scope' keyword.

--bb