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