www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why are scope variables being deprecated?

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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.
}
Jul 26 2012
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
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? You get undefined behavior, because foo doesn't exist anymore. If you really need foo to be on the stack, then maybe you should make it a struct. However, if you really do need scope for some reason, then you can use std.typecons.scoped, and it'll do the same thing. 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. So, they're being removed and put into the standard library instead. - Jonathan M Davis
Jul 26 2012
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 07/26/2012 09:19 PM, 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? You get undefined behavior, because foo doesn't exist anymore. If you really need foo to be on the stack, then maybe you should make it a struct. However, if you really do need scope for some reason, then you can use std.typecons.scoped, and it'll do the same thing.
OK, so std.typecons.scoped will completely replace the use-case for the scope keyword. That makes it OK ;) Just making things structs isn't always sufficient because the data type in question might be in a 3rd party's code and cannot be simply redesigned. The scope keyword gave us a way to force stack-allocation in cases that would be otherwise inaccessible. But it seems like std.typecons.scoped can be used for this, so 'scope' isn't need anymore. And it simplifies the compiler. Cool. Erm, yeah I'm sure you've probably seen this discussed to death already. I know how these things go ;)
 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. So, they're being removed and put into the standard
 library instead.

 - Jonathan M Davis
Alright. Thanks for the good explanation!
Jul 26 2012
prev sibling parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
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.
 You get undefined behavior, because foo
 doesn't exist anymore.
Excuse me, but no, compiler should prevent escaping scope references just like it does with scope parameters (I know it's currently implemented just for delegates).
 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.
 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.
 However, if you really do need scope for some
 reason, then you can use std.typecons.scoped, and it'll do the same 
thing. scoped is more dangerous than language solution. See: class A { } __gshared A globalA; static this() { auto a = scoped!A; globalA = a; } 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.
Oct 10 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Piotr Szturmaj:

 It seems that we ended up with a solution that was meant to fix 
 a language builtin but appears to be worse than that.
This is true, currently the library solution is worse (more dangerous and more broken) than the precedent built-in feature. But there is hope to have a good solution someday (mixing library code and some kind of built-support), while a broken built-in is not good. Andrei did the right thing: if you don't have a feature it's kind of easy to add something, while fixing some bad built-in is rather harder. Bye, bearophile
Oct 10 2012
parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
bearophile wrote:
 Piotr Szturmaj:

 It seems that we ended up with a solution that was meant to fix a
 language builtin but appears to be worse than that.
This is true, currently the library solution is worse (more dangerous and more broken) than the precedent built-in feature. But there is hope to have a good solution someday (mixing library code and some kind of built-support), while a broken built-in is not good. Andrei did the right thing: if you don't have a feature it's kind of easy to add something, while fixing some bad built-in is rather harder.
Wasn't it broken because preventing escaping of scoped references was not implemented?
Oct 10 2012
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Oct 10 2012
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
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.
Oct 10 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, October 11, 2012 01:24:40 Piotr Szturmaj wrote:
 Could you give me an example of preventing closure allocation? I think I
 knew one but I don't remember now...
Any time that a delegate parameter is marked as scope, the compiler will skip allocating a closure. Otherwise, it has to copy the stack from the caller onto the heap to create a closure so that the delegate will continue to work once the caller has completed (e.g. if the delegate were saved for a callback and then called way later in the program). Otherwise, it would refer to an invalid stack and really nasty things would happen when the delegate was called later. By marking the delegate as scope, you're telling the compiler that it will not escape the function that it's being passed to, so the compiler then knows that the stack that it refers to will be valid for the duration of that delegate's existence, so it knows that a closure is not required, so it doesn't allocate it, gaining you efficiency. - Jonathan M Davis
Oct 10 2012
parent reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
Jonathan M Davis wrote:
 On Thursday, October 11, 2012 01:24:40 Piotr Szturmaj wrote:
 Could you give me an example of preventing closure allocation? I think I
 knew one but I don't remember now...
Any time that a delegate parameter is marked as scope, the compiler will skip allocating a closure. Otherwise, it has to copy the stack from the caller onto the heap to create a closure so that the delegate will continue to work once the caller has completed (e.g. if the delegate were saved for a callback and then called way later in the program). Otherwise, it would refer to an invalid stack and really nasty things would happen when the delegate was called later. By marking the delegate as scope, you're telling the compiler that it will not escape the function that it's being passed to, so the compiler then knows that the stack that it refers to will be valid for the duration of that delegate's existence, so it knows that a closure is not required, so it doesn't allocate it, gaining you efficiency.
Thanks, that's clear now, but I found a bug: __gshared void delegate() global; void dgtest(scope void delegate() dg) { global = dg; // compiles } void dguse() { int i; dgtest({ writeln(i++); }); } I guess it's a known one.
Oct 10 2012
parent Don Clugston <dac nospam.com> writes:
On 11/10/12 02:30, Piotr Szturmaj wrote:
 Jonathan M Davis wrote:
 On Thursday, October 11, 2012 01:24:40 Piotr Szturmaj wrote:
 Could you give me an example of preventing closure allocation? I think I
 knew one but I don't remember now...
Any time that a delegate parameter is marked as scope, the compiler will skip allocating a closure. Otherwise, it has to copy the stack from the caller onto the heap to create a closure so that the delegate will continue to work once the caller has completed (e.g. if the delegate were saved for a callback and then called way later in the program). Otherwise, it would refer to an invalid stack and really nasty things would happen when the delegate was called later.
>
 By marking the delegate as scope, you're telling the compiler that it
 will not
 escape the function that it's being passed to, so the compiler then
 knows that
 the stack that it refers to will be valid for the duration of that
 delegate's
 existence, so it knows that a closure is not required, so it doesn't
 allocate
 it, gaining you efficiency.
Thanks, that's clear now, but I found a bug: __gshared void delegate() global; void dgtest(scope void delegate() dg) { global = dg; // compiles } void dguse() { int i; dgtest({ writeln(i++); }); } I guess it's a known one.
Looks like bug 5270?
Oct 11 2012