auto, var, raii,scope, banana

[Chris Nicholson-Sauls]

Kirk McDonald wrote:
> Maybe we could decide that based on the keyword's placement:
> 
> class C {
>     int m_i;
>     this(int i) { m_i = i; }
>     int i() { return m_i; }
> }
> 
> scope C a = new C(1); // Destroy 'a' at end of scope
> C b = a; // b is another reference to 1. It will be invalid at the
>          // end of scope, except:
> a = new C(2); // No, whoops! Destroy 2 at end of scope.
>               // 1 is now referenced by b alone.
> return b; // Allowed! The reference 'a' will no longer destroy 1.
> return a; // NOT allowed! a is a scoped reference
> 
> The alternative:
> 
> C a = scope new C(1); // Destroy 1 at end of scope.
> C b = a; // b is another reference to 1, which will be destroyed
>          // at the end of scope.
> a = new C(2); // A new, plain-old GCed instance.
> return b; // NOT allowed! 1 is invalid after this scope.
> return a; // Okay. a is a reference to a regular object.
> 
> Maybe we could allow both?
> 

Sounds reasonable to me, and potentially quite useful (even if often primarily for 
self-documenting code design, as I suspect in the vast majority of use-cases the effect 
will be identical).

I also think it might very well be reasonable to disallow using 'scope' in tandem with 
either of 'static' or 'const' as the meaning is... well, questionable.  Except perhaps for 
'static' in the sole case of recursive functions, in which case I suppose the entity 
exists until the entire call-stack has unwound.  Potentially useful.  Allowing 'scope 
auto' seems harmless, although redundant since 'scope' as a storage class should allow for 
type-inference via precedance alone.

-- Chris Nicholson-Sauls