Auto syntax REALLY revisited

[Georg Wrede]

Georg Wrede wrote:
> Georg Wrede wrote:
>> Mike Capp wrote:
>>> 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."

Currently (D.144) it _is_ allowed. (Obviously a bug.)

>> If 'local' were implemented, then it could, since then the meaning
>> of 'auto' would only mean auto-typing and not RAII.
> 
> On second thought,
> 
> local Bla bla = new Bla();     // RR, heap storage
> auto bla = new Bla();          // autotyped, heap storage
> Bla bla = new Bla();           // heap storage
> local Bla bla = local Bla();   // RR, stack storage
> auto bla = local Bla();        // autotyped, stack storage, no RR
> Bla bla = local Bla();         // stack storage, no RR 

Reordering the lines above might make it clearer:

local Bla bla = new Bla();     // RR, heap storage
local Bla bla = local Bla();   // RR, stack storage
auto bla = new Bla();          // autotyped, heap storage
auto bla = local Bla();        // autotyped, stack storage, no RR
Bla bla = new Bla();           // heap storage
Bla bla = local Bla();         // stack storage, no RR

and consequently also:

local auto bla = new Bla();     // RR, autotyped, heap storage
local auto bla = local Bla();   // RR, autotyped, stack storage

> This brings up a few problems. First, the word 'local' is just about
> as smart as 'auto', i.e. it is misleading and ambiguous for what
> we're using it for.
> 
> Second, do we really need this fine of a control over both storage
> and disposal?
> 
> For the compiler writer, at first sight, keeping track of RR (RAII)
> here might look like a lot of work. But it actually is ok: "the
> variable knows" whether to invoke RR, so RR will be invoked
> irrespective of who happens to be referenced by it.
> 
> This may actually open up new ways of using RR?


Sigh, shouldn't try to think before noon:

> One potential, hard problem is, this decouples RR-ness from the
> object instance, making it a property of the reference (the
> variable). This is obviously not in the spirit of why we have RR in
> the first place.

Ok, RR-ness can be coupled with

  - the reference
  - the assignment
  - the instance
  - the class

Of these, I'd see that instance and class should be made equivalent, 
since it would be clearer to have separate classes (one requiring RR and 
the other not) for purposes where _sometimes_ the instance absolutely 
needs to be RR only. (As opposed to storing knowledge of such a need in 
an instance variable.)

Currently (D.144) couples RR-ness with the reference. Which is sort of 
ok, *except* for the fact that one now can assign (e.g.) a global 
instance to the reference, thus (probably inadvertently) marking it for 
impending destruction. One can also assign an instance created as RR to 
(e.g.) a global variable, and then get surprised at the later occurring 
access violation because the instance got destroyed, even if other 
references to it exist.

Coupling RR-ness with the assignment is an intriguing alternative. This 
has the possibility of creating really robust code.

Then the compiler could prevent other assignments to the reference, and 
it could prevent assignment of the instance to any variable with a 
longer scope than the original reference.

> ----
> 
> Unless we can sort out what we want here, I think the current state
> of RR is adequate -- _except_ that I want another word substituted
> for 'auto'! We can't have it mean "autotype and/or RAII", at the same
> time. That is just too much of a disgrace.

To summarize:

It would be handy to have a class that _requires_ RR instantiation.

It would also be handy if RR is with the assignment. (That is, 
forcefully welding the reference and the instance together.)