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'd like to see 'auto' remain as it is except for RAII. RAII only makes sense for classes and dynamic arrays, for these 'auto' would only be useful for automatic type inference. E.g: 'auto C c = new C;' is useless and the same as 'C c = new C;'

I'd like to see 'scoped' as a new storage class for classes and dynamic arrays. Using it for anything else should be an error. This would mean that 'auto class' would become 'scoped class' too.

I'd hate to see 'var', 'let', 'def' etc. introduced as new keywords! Typing time differences for 3-6 letters is in the milliseconds for most coders (I would think)

I hope I haven't missed something fundamental, and would be extremely pleased if D 1.0 turns out like this :)

*shivers* by the thought of 'var'

Tomas Lindquist Olsen wrote:
> Walter Bright wrote:

> I'd like to see 'scoped' as a new storage class for classes and dynamic arrays. Using it for anything else should be an error. This would mean that 'auto class' would become 'scoped class' too.

I think

  scoped int a = expr;

should be ok. Allowing that enables you to treat value types and classes uniformly in some template usages.

    {
       scoped T a = make_temp_var();
       ...
    }
    // a has been cleaned up here, whether it was a class or not

I don't have a specific use case in mind, but it seems there's no reason to not allow it, since a basic value type acts like it's scoped anyway.


--bb

Sean Kelly wrote:
> 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.

Actually that's not so bizzare at all, because "new" already accepts parameters.

http://digitalmars.com/d/memory.html#stackclass

With a little magic, you can achieve the same effect, using:

MyClass c = new (alloca(MyClass.classinfo.init.length)) MyClass;

Now, /that/ is bizzare. It would be very nice IMHO if there was a simpler way to do it, such as

var c = new(scope) MyClass;

> 
> 
> Sean

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'm going to chime in with the people who don't like (5).  I'd much prefer reusing 'scope' or some such.

On Mon, 13 Nov 2006 01:58:21 -0500, Chad J 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". 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'm going to chime in with the people who don't like (5).  I'd much prefer reusing 'scope' or some such.

Has anyone worked out how to grep for instances of RAII and/or TI using this proposed syntax? I mean if I wanted to locate all the places where I was using (only) RAII, what would be the regular expression to do that? The same with TI? I'm sure it can be done but I'm no RE guru.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
13/11/2006 6:26:08 PM

Bill Baxter wrote:
> Walter Bright wrote:
>> 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?

I don't think it'll be ambiguous. scope isn't a type or a function, there is no:
	static (a) = 3;
allowed anyway. The rule would be:
	scope (
means a scope statement, otherwise scope would be a storage class.

Walter Bright wrote:
> Bill Baxter wrote:
>> Walter Bright wrote:
>>> 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?
> 
> I don't think it'll be ambiguous. scope isn't a type or a function, there is no:
>     static (a) = 3;
> allowed anyway. 

Ah, I hadn't tried that.  I assumed it would be OK, too.

> The rule would be:
>     scope (
> means a scope statement, otherwise scope would be a storage class.

Yeh, that works given the above.  Whew!


--bb

Tomas Lindquist Olsen wrote:
> *shivers* by the thought of 'var'

I knew that somehow I couldn't be the only one <g>.

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

You are right, your concern is outdated.

Take "var" from ECMAScript, so you don't need to get dirty with Pascal (we won't tell anyone).

And, maybe, with "var" you can attract some old Pascal programmer.

Ciao
---
http://www.mariottini.net/roberto/

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.

On the other hand: D is the right language to bridge that gap!

Is there some a priori reason why there are those two groups? Probably not, since in the end they want to achieve the same thing: write a program to fix a problem.

You're afraid of turning against the C crowd, but the C crowd is exactly the group that falls over "auto" meaning two things. In fact, they're probably the ones that don't like "auto" meaning anything other than its original C meaning. They should in fact be happy with "var" :)

L.