DIP1000

[Loara]

On Tuesday, 28 June 2022 at 21:58:48 UTC, Ola Fosheim Grøstad 
wrote:
> Not when connect returns, but the scope that connect was called 
> from. Still, this can be deduced, you just have to give the 
> scopes an ordering.

The deduction can happen even if you don't use `scope` attribute. 
When you use `scope` attribute you're saying to compiler "You 
have to allocate this object on the stack, don't try to use heap 
allocation". If you want to let compiler to decide what is the 
best approach then don't use `scope`.

> Well, that is a flaw, if the object is stack allocated then the 
> fields are too.

No because:

`scope` variable === the variable is a pointer/reference that 
points to stack allocated data

So `scope int v;` is equal to `int v;` since `v` is not a 
pointer, whereas `scope int *p` is different from `int *v;` since 
the latter can't point to stack allocated integers. This is the 
difference.

Since stack allocated objects are destroyed in the reverse order 
allowing a recursive `scope` attribute is a bit dangerous as you 
can see in the following example:

```d

struct A{
   int *i;

   ~this(){
     writeln(*i);
   }
}
...
  {
   A a;
   int i = 2;
   ...
   scope int *j = &i;
   scope A *b = &a;
   (*b).i = j;
  } // i is destroyed before a
```

> The compiler could easily deduce it. It is not difficult to see 
> what the life time constraint must be.

Again if you want to let the compiler to deduce then don't use 
`scope`.