Fredrik Olsson wrote:
> And the possibility of allowing non stack objects to automatically go
> out of scope in the future without changing the syntax? 

This is important. For the destruction itself, it makes no difference whether an object is on the stack or on the heap.

A programmer might have an opinion on where to initially store the object, but that has to do with issues like heap fragmentation, or whatever else except destruction details.

> Ones we go 1.0 much of the syntax will
> pretty much have to stay, so better be prepared :). A functionality
> restricted by the compiler is easier to fix and causes less harm than
> a feature restricted by the syntax.

True!

> Plus with: auto a = A(); It is absolutely no way to just at a glance
> make sure with 100% sertenty that a is not assigned the result of a
> function, instead of being instantiated on the stack.

Yes. And even more important, it should be obvious and stand out to the human reader -- or else debugging becomes a pain.

That is, if the programmer has an opinion on where the object should be, then that opinion should stand out. If he doesn't care, then that should be the simplest syntax.

Likewise, and /separately/ from that, it should be equally obvious if the programmer wanted it to be a scoped object. But if he didn't, then it does _not_ have to stand out (i.e. use normal syntax here), since the default has always been to not force immediate destruction.

james wrote:
> Could auto also be used in class definitions as well as stack finalisaton of
> objects e.g
> 
> class X {
> 
> // the object is destroyed automatically when the class X is destroyed.
> auto A a = new A();
> }

(You mean _instance_ above, right? Classes don't get destroyed.)

> Personally i would like the above use of auto and make gc explicit ie:
> gc A a = new A();

GC has nothing to do with this.

If a programmer wants an object destroyed immediately after going out of scope (by whatever mechanism it may eventually happen), then this applies to GC collected programs as well as non-GC-collected. (e.g. C++)

In article <43FC743C.9090601@nospam.org>, Georg Wrede says...
>
>james wrote:
>> Could auto also be used in class definitions as well as stack finalisaton of objects e.g
>> 
>> class X {
>> 
>> // the object is destroyed automatically when the class X is destroyed.
>> auto A a = new A();
>> }
>
>(You mean _instance_ above, right? Classes don't get destroyed.)
Correct.


>> Personally i would like the above use of auto and make gc explicit ie:
>> gc A a = new A();
>
>GC has nothing to do with this.
>
>If a programmer wants an object destroyed immediately after going out of scope (by whatever mechanism it may eventually happen), then this applies to GC collected programs as well as non-GC-collected. (e.g. C++)
It seems that the debate on auto has to do with how much explicit control the programmer has over object creation/destruction and memory management. Programmers who like auto are probably less keen on gc. And maybe would prefer it as optional rather than by default. Though technically auto and gc are not related.

Fredrik Olsson wrote:
> After some discussion on #d I though why not put my thoughts into more permanent writing.
> 
> Keyword auto is used for two reasons; implicit type and making sure the object is destroyed when going out of scope. I suggest a new keyword for the latter: local.
> 

Regardless of semantic changes (as a semantic change in auto-RAII might make it work without keyword), I wish for:
 auto for auto-RAII
 var for auto-type
Why these names? Auto-RAII implies an action in run-time, whereas auto-type is a compile-time only action, with no run-time effects. The name 'auto' sounds more action-like than 'var', so it fits better being assigned to auto-RAII.
Also, 'var' is shorter than 'auto', with only three letters, which is also nice, since auto-type is mainly a syntactic sugar feature, so with 'var' it is one less character to type.

I wonder what Walter's plans for this are. It's been a while since this ambiguity was introduced and news on this have come.

-- 
Bruno Medeiros - CS/E student
"Certain aspects of D are a pathway to many abilities some consider to be... unnatural."