Bug 14492 – Deprecate scope for allocating classes on the stack

Raising issue for deprecating scope for allocating classes on the stack. See: http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack

Is this feature not used in Phobos?

(In reply to bearophile_hugs from comment #1) > Is this feature not used in Phobos? The only place that I see it in Phobos is in a bit of code in std.datetime that Kenji refactored a while back. No idea what it's used there. Something to do with the windows registry. There might be a couple of other places, but it's quite rare. Part of that though is the fact that classes are quite rare in Phobos. The only official place that I'm aware of where scope is used much at all is in ddmd. I expect that it will be trivial to remove it entirely from Phobos, but I don't know what it'll take to remove it from ddmd.

As Jonathan said, it's used in DDMD. What we really need is a way to make it @safe, not deprecating it.

(In reply to yebblies from comment #3) > As Jonathan said, it's used in DDMD. What we really need is a way to make > it @safe, not deprecating it. Why aren't you using std.typecons.scoped? In theory, at least, that's supposed to replace all uses of scope classes. But regardless, I don't see how you could possibly make it @safe without somehow guaranteeing that no reference to the object escapes, and I'd be surprised if you could talk Andrei into thinking that scope should stay. I'm not sure what Walter's take on it would be though. But it _was_ decided some time ago that scope classes were being gotten rid of, so it's not like this is new.

(In reply to Jonathan M Davis from comment #4) > (In reply to yebblies from comment #3) > > As Jonathan said, it's used in DDMD. What we really need is a way to make > > it @safe, not deprecating it. > > Why aren't you using std.typecons.scoped? In theory, at least, that's > supposed to replace all uses of scope classes. But regardless, I don't see > how you could possibly make it @safe without somehow guaranteeing that no > reference to the object escapes, and I'd be surprised if you could talk > Andrei into thinking that scope should stay. I'm not sure what Walter's take > on it would be though. But it _was_ decided some time ago that scope classes > were being gotten rid of, so it's not like this is new. Let's fix scoped!() first. See Issue #10921

(In reply to Jonathan M Davis from comment #4) > (In reply to yebblies from comment #3) > > As Jonathan said, it's used in DDMD. What we really need is a way to make > > it @safe, not deprecating it. > > Why aren't you using std.typecons.scoped? In theory, at least, that's > supposed to replace all uses of scope classes. But regardless, I don't see > how you could possibly make it @safe without somehow guaranteeing that no > reference to the object escapes, and I'd be surprised if you could talk > Andrei into thinking that scope should stay. I'm not sure what Walter's take > on it would be though. But it _was_ decided some time ago that scope classes > were being gotten rid of, so it's not like this is new. To avoid depending on phobos, for now. If we get some form of 'scope' in the language eventually we will hopefully be able to use it safely again.

DDMD still depends on this heavily. For now scope class is going nowhere, if the idea of deprecating it hasn't already been completely reversed.

(In reply to Iain Buclaw from comment #7) > DDMD still depends on this heavily. For now scope class is going nowhere, > if the idea of deprecating it hasn't already been completely reversed. If I understand DIP 1000 correctly, I think that the original meaning of scope on class reference is basically becoming an optimization done with scope rather than the direct purpose of the feature, and the work with DIP 1000 should in theory make it @safe. So, if DIP 1000 is accepted (and I assume it will be once it's ready, since it's Walter who's doing it, and he's spent a lot of time on it), then scope on class references is here to stay.

Yes, scope on class references is here to stay since there is no other way to express that a reference to a class should not escape the current scope.