Why are scope variables being deprecated?

[Piotr Szturmaj]

Jonathan M Davis wrote:
> 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.

Yes, I know the difference between scope parameters and variables, but I 
thought that they both can be considered "scope references" which can't 
be escaped.

I don't support restoring scope variables in their previous state. But I 
think I know a way to make scope variables safe by default.

> 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.

Could you give me an example of preventing closure allocation? I think I 
knew one but I don't remember now...

With regards to escaping scope reference parameters, I hope that 
eventually they all will be blocked by the compiler, not only 
delegate/closure case.

>>> 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.

I know, class on the stack really become a "value" type. But it's still 
useful. You can use non-scope classes with polymorhism as usual, but 
when needed you can allocate one concrete class on the stack. You can't 
assign subclass reference to scope class variable, but you still can 
assign scope class reference to non-scope ancestor class references. 
This may or may _not_ escape. I'm proposing that escaping assignments 
should be blocked.

>>> 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.

OK.

>> 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).

I agree about delete operator, but as I wrote above, I'm not sure, but I 
might know a way to make scope variables safe. I need to think about this :)

> 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.

I see, but scope might be also used in other scenarios, like emplacing 
classes inside other classes.