dynamically allocating on the stack

[Jonathan M Davis]

On Sunday, April 22, 2018 01:07:44 Giles Bathgate via Digitalmars-d-learn 
wrote:
> On Saturday, 21 April 2018 at 19:06:52 UTC, Steven Schveighoffer
>
> wrote:
> > alloca is an intrinsic, and part of the language technically --
> > it has to be.
>
> Why does:
>
> scope c = new C();       // allocate c on stack
> scope a = new char[len]; // allocate a via gc?

Because prior to DIP 1000 being introduced, scope did absolutely nothing to
parameters if they weren't delegates, and it did nothing to other variables
if they weren't classes. So, without -dip1000, scope is ignored on the
second line. scope on parameters was to tell the compiler that the delegate
didn't escape so that it didn't have to allocate a closer. scope on classes
was to force them to be allocated on the stack and have a deterministic
lifetime, since classes normally live on the heap. Without -dip1000, it's
completely unsafe to do, because the compiler makes no guarantees about
references to the class not escaping, which is why std.typecons.scoped was
introduced to replace it, and scope on classes was going to be deprecated.

However, when Walter was looking into improving @safety with ref and adding
some sort of ref-counting mechanism into the language, he found that he
needed better guarantees about the lifetime of some objects in @safe code in
order to be able to guarantee @safety. So, he came up with DIP 1000, which
expands scope to do a lot more. The result is that scope has been greatly
expanded with DIP 1000 and its meaning has subtly changed. It becomes closer
to what it meant for parameters that were delegates in that it makes
guarantees about no references or pointers or whatnot to an object escaping
the scope. The effect on classes is then retained, but it becomes an
optimization that the compiler can do as a result of what scope allows it to
guarantee rather than an instruction by the programmer to tell the compiler
to put the object on the stack. As such, the optimization could
theoretically be expanded to affect any call to new where the result is
assigned to variable that's marked with scope rather than just classes, but
I don't think that it has been yet. Also, because scope is then forced to be
used in enough places to allow the compiler to make guarantees about the
lifetime of the object and not allow it to escape, the @safety issues with
scope on classes is fixed, which more or less negates the need for
std.typecons.scoped, and the deprecation for scope on classes has therefore
been nixed.

However, unless -dip1000, the only status quo is still in effect, making
scope on classes very much unsafe, and until -dip1000 is the default
behavior (which will probably be a while), we really can't take advantage of
the improvements that it's supposed to provide (and currently, because
-dip1000 makes ABI-incompatible changes, you have to have compiled your
entire software stack - Phobos included - with -dip1000 to use it, meaning
that it's mostly unusable right now).

- Jonathan M Davis