Bug 5112 – scope is deprecated, but this is not mentioned in the specification

See title. The scope keyword is to be deprecated, but this is mentioned no where in the specification.

A *specification* should not list planned future changes at all. Besides, such a list cannot satisfy any objective standard for completeness. And could you please post a link to Walter's message on what you're on about?

(In reply to comment #1) > A *specification* should not list planned future changes at all. Besides, such > a list cannot satisfy any objective standard for completeness. > > And could you please post a link to Walter's message on what you're on about? Here's a relevant link: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=114064 Andrei - "Walter plans to change the documentation to reflect the demise of delete and scope storage class." I agree to some extent that planned changes should not necessarily be in the specification, but they definitely need to be somewhere, and I see no harm in at least putting a note in the specification that these features are scheduled for deprecation. Currently, the only way to know about the status of scope and delete is to be a regular on the news groups. This is, of course, unacceptable. There needs to be some authoritative reference for people to refer to, so that people can learn the language without reading the news groups.

(In reply to comment #2) > Here's a relevant link: > http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=114064 Far better to link to the archives. http://www.digitalmars.com/d/archives/digitalmars/D/Re_poll_about_delete_114014.html#N114064 > Andrei - "Walter plans to change the documentation to reflect the > demise of delete and scope storage class." If it's just something Walter's said to somebody in personal communication, IMO it needs to be taken with at least a pinch of salt. > I agree to some extent that planned changes should not necessarily > be in the specification, but they definitely need to be somewhere, > and I see no harm in at least putting a note in the specification > that these features are scheduled for deprecation. Not without an indication of what its replacement is going to be. > Currently, the only way to know about the status of scope and > delete is to be a regular on the news groups. It's worse than that. The only way to know is to either happen to read this particular message in the newsgroups or be in the pattern of reading every message in detail. Besides, the scope keyword is three things: (a) a storage class (b) a class attribute (c) a means of doing scope guards So when you say "The scope keyword is to be deprecated", you really just mean "meaning (a) of scope is to be deprecated".

There's still talk about the proper role for scope, so I prefer to leave this as is at the moment.

I thought that it was already decided what part of scope was being kept. What's left to decide on this? In particular, as I understand it, it's definitive that scope on local variables is going away and that std.typecons.Scoped is to be used instead. If that is indeed the case, we really should at least update the compiler and the docs to take that into account or people are going to keep using it and that much more code will break when it's finally deprecated. We really need to sort out whatever's left to sort out with this so that we can reduce code breakage due to the resulting language changes.

As Jonathan said, if we know scope for locals is going then it shouldn`t be mentioned. It currently is under Scope Classes http://dlang.org/class.html Related bug: http://d.puremagic.com/issues/show_bug.cgi?id=2120

It's now listed on the deprecations page: http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack As for cleaning up any left references to scope in the documentation, see Issue 6179.