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.

local auto foo = new Bar();

Why? First of auto is only used for the implicit type, so no confusion.  The keyword local in itself describes pretty to the point what is supposed to happen with the variable. And nothing is said about the stack, so we are future proof if in the future we would like to also have:

local auto foo = Bar();

Where Bar(); is a function returning an Object, but we still want the object to be destructed when going out of this scope. The implementation is quite different as the Object would need to be on heap, but the syntax is the same. So local would indicate what should be done (destroy when out of scope), not how it should be done (allocate on stack or whatever).

Even this could be possible, without syntax changes:
{
  local Foo bar;
  // some code
  Baz(bar); // Jupp Baz have a inout parameter returning an object.
} // And bar is still destroyed if set to something here...


regards
// Fredrik Olsson

On Tue, 21 Feb 2006 07:23:26 +1100, Fredrik Olsson <peylow@gmail.com> 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.

Its got my vote. A much better idea that having 'auto' overloaded.

-- 
Derek Parnell
Melbourne, Australia

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.
> 
> local auto foo = new Bar();
> 
> Why? First of auto is only used for the implicit type, so no confusion.  The keyword local in itself describes pretty to the point what is supposed to happen with the variable. And nothing is said about the stack, so we are future proof if in the future we would like to also have:
> 
> local auto foo = Bar();
> 
> Where Bar(); is a function returning an Object, but we still want the object to be destructed when going out of this scope. The implementation is quite different as the Object would need to be on heap, but the syntax is the same. So local would indicate what should be done (destroy when out of scope), not how it should be done (allocate on stack or whatever).
> 
> Even this could be possible, without syntax changes:
> {
>   local Foo bar;
>   // some code
>   Baz(bar); // Jupp Baz have a inout parameter returning an object.
> } // And bar is still destroyed if set to something here...
> 
> 
> regards
> // Fredrik Olsson

What ever the final syntax/semantics may be, a new keyword is a better solution.

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.
> 
> local auto foo = new Bar();

If we're moving towards stack-based auto classes then I'd prefer the distinction be associated with the object and not the reference.  ie.

auto foo = local Bar();

I think the distinction is important because foo can be reassigned to a non-local object.  Alternately, simply omitting 'new' entirely might be feasible, though the meaning there is less obvious.  As I said in #d:

Foo Bar() { return new Foo(); }

auto foo = Bar();

looks like a stack-based initialization even though it's not.  But perhaps it doesn't matter in this case, as nothing will break if a heap-based instance is used in place of a stack-based instance, it's replacing things the other direction that can cause problems.


Sean

> auto foo = local Bar();

This gets my vote , but why is everyone using 'auto' ( deduction )keyword here, gets a little confusing since you're trying to replace the other auto with local.  ( For people not in on the #d discussion ).


MyClass foo = local MyClass("parameters");

yes ?

So 'local' replaces 'new' for stack based allocations.



"Sean Kelly" <sean@f4.ca> wrote in message news:dtdb2e$2lsp$1@digitaldaemon.com...
> 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.
> >
> > local auto foo = new Bar();
>
> If we're moving towards stack-based auto classes then I'd prefer the distinction be associated with the object and not the reference.  ie.
>
> auto foo = local Bar();
>
> I think the distinction is important because foo can be reassigned to a non-local object.  Alternately, simply omitting 'new' entirely might be feasible, though the meaning there is less obvious.  As I said in #d:
>
> Foo Bar() { return new Foo(); }
>
> auto foo = Bar();
>
> looks like a stack-based initialization even though it's not.  But perhaps it doesn't matter in this case, as nothing will break if a heap-based instance is used in place of a stack-based instance, it's replacing things the other direction that can cause problems.
>
>
> Sean

Charles wrote:
>> auto foo = local Bar();
> 
> This gets my vote , but why is everyone using 'auto' ( deduction )keyword
> here, gets a little confusing since you're trying to replace the other auto
> with local.  ( For people not in on the #d discussion ).

Just to make things extra confusing :-)

> MyClass foo = local MyClass("parameters");
> 
> yes ?
> 
> So 'local' replaces 'new' for stack based allocations.

Yes.


Sean

In article <dtdb2e$2lsp$1@digitaldaemon.com>, Sean Kelly says...
>
>If we're moving towards stack-based auto classes then I'd prefer the distinction be associated with the object and not the reference.  ie.
>
>auto foo = local Bar();
>
>I think the distinction is important because foo can be reassigned to a non-local object.

Not currently, it can't. From http://www.digitalmars.com/d/attribute.html#auto : "Assignment to an auto, other than initialization, is not allowed."

cheers,
Mike

While I agree with your sentiment.  However, I think local associated with the reference is confusing as it leads people to believe it is somehow different from "global." (See Python's usage of these keywords) This would make much more sense associated with the object, like Sean kelly mentioned.  However, there is still problems with that.

While we're coming to a consensus on these things, let us fix the reuse of static, and the !is keyword as well.

-S.


On 2006-02-20 12:23:26 -0800, Fredrik Olsson <peylow@gmail.com> said:

> 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.
> 
> local auto foo = new Bar();
> 
> Why? First of auto is only used for the implicit type, so no confusion.   The keyword local in itself describes pretty to the point what is supposed to happen with the variable. And nothing is said about the stack, so we are future proof if in the future we would like to also have:
> 
> local auto foo = Bar();
> 
> Where Bar(); is a function returning an Object, but we still want the object to be destructed when going out of this scope. The implementation is quite different as the Object would need to be on heap, but the syntax is the same. So local would indicate what should be done (destroy when out of scope), not how it should be done (allocate on stack or whatever).
> 
> Even this could be possible, without syntax changes:
> {
>    local Foo bar;
>    // some code
>    Baz(bar); // Jupp Baz have a inout parameter returning an object.
> } // And bar is still destroyed if set to something here...
> 
> 
> regards
> // Fredrik Olsson

Sean Kelly wrote:
> 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.
>>
>> local auto foo = new Bar();
> 
> 
> If we're moving towards stack-based auto classes then I'd prefer the distinction be associated with the object and not the reference.  ie.
> 
> auto foo = local Bar();
> 
> I think the distinction is important because foo can be reassigned to a non-local object. 

Bull's eye! Funny that nobody thought of this before.

> Alternately, simply omitting 'new' entirely might be feasible, though the meaning there is less obvious.  As I said in #d:
> 
> Foo Bar() { return new Foo(); }
> 
> auto foo = Bar();
> 
> looks like a stack-based initialization even though it's not.  But perhaps it doesn't matter in this case, as nothing will break if a heap-based instance is used in place of a stack-based instance, it's replacing things the other direction that can cause problems.

In general, it's much harder to spot something is missing than to spot the wrong thing. So, I definitely vote for the keyword 'local' for stack storage.

Besides, that's what it means in other languages, too.

Much cleaner: new allocates on heap, local on stack.

Mike Capp wrote:
> In article <dtdb2e$2lsp$1@digitaldaemon.com>, Sean Kelly says...
> 
>> If we're moving towards stack-based auto classes then I'd prefer
>> the distinction be associated with the object and not the
>> reference.  ie.
>> 
>> auto foo = local Bar();
>> 
>> I think the distinction is important because foo can be reassigned
>> to a non-local object.
> 
> Not currently, it can't. From
> http://www.digitalmars.com/d/attribute.html#auto : "Assignment to an
> auto, other than initialization, is not allowed."

If 'local' were implemented, then it could, since then the meaning of 'auto' would only mean auto-typing and not RAII.