Why are scope variables being deprecated?

[Jonathan M Davis]

On Wednesday, October 10, 2012 17:04:41 Piotr Szturmaj wrote:
> Jonathan M Davis wrote:
> > On Thursday, July 26, 2012 21:09:09 Chad J wrote:
> >> I keep hearing that scope variables are going away. I missed the
> >> discussion on it. Why is this happening?
> >> 
> >> When I read about this, I have these in mind:
> >> 
> >> void someFunc()
> >> {
> >> 
> >> // foo is very likely to get stack allocated
> >> scope foo = new SomeClass();
> >> foo.use();
> >> // ~foo is called.
> >> 
> >> }
> > 
> > It's inherently unsafe. What happens if you returned a reference to foo
> > from someFunc? Or if you assigned a reference to foo to anything and then
> > tried to use it after someFunc has returned?
> 
> Why scope parameters are not deprecated then? It's the same situation.

No. scope on parameters is completely different from scope on local variables. 
scope on local variables puts the variable on the stack - even if it's a 
class.

scope on function parameters is supposed to make it so that the compiler 
prevents any references escaping (which potentially really restricts how you 
can use the parameter). The only case where that would affect where a variable 
is placed is that it makes it so that a closure isn't created for delegates 
(which is the one place that scope on parameters actually works semi-
properly). So, the two uses of scope do completely different things.

> > If you really need foo to be on the stack, then maybe
> > you should make it a struct.
> 
> Then you lose some useful class features.

What you lose is polymorphism, which doesn't work on the stack anyway. 
Polymorphism is only applicable when you have a reference which could be of a 
base class type rather than the derived type that the object actually is. 
Objects on the stack must be their exact type.

> > scope on local variables is going away for pretty much the same reason
> > that
> > delete is. They're unsafe, and the fact that they're in the core language
> > encourages their use.
> 
> That's not convincing for me. Pointers are also unsafe, and they're in
> the core language.

Pointers aren't unsafe. Certain operations are unsafe. Note that pointers are 
perfectly legal in @safe code. It's pointer arithmetic which isn't.

> and this compiles (http://dpaste.dzfl.pl/6c078e66). With scope storage
> class compiler would prevent this escaping assignment. It seems that we
> ended up with a solution that was meant to fix a language builtin but
> appears to be worse than that.

It may very well be more dangerous, and that may or may not be fixable, but if 
it's at the language level, then a lot more people are likely to use it, and 
it's dangerous no matter where it is and shouldn't be used under normal 
circumstances. Providing the feature is one thing. Making it easy to use is 
another. It's like delete. It's dangerous and shouldn't be used normally, so 
having it in the language where everyone will use it is too dangerous, so a 
library solution is used instead. It therefore becomes more of a power user 
feature (as it should be).

But regardless of the various pros and cons, it was decided ages ago that
it was not worth have scope on local variable be part of the language any
more. So, it's definitely going away.

- Jonathan M Davis