> The issue is that the scope keyword is impossible to check against > escapes without extra additions to the language (e.g. marking a method > or a function parameter as scoped). Such an uncheckable pattern is best > left to a library feature, it doesn't deserve a keyword. I agree that > scoped() has weaknesses that should be looked into, but scope must go. > > Andrei
In D2.0 I like the scope storage for optionally allocating a class on the stack, and found a use for it. The class was specially designed to be aware of its storage status. class FlexyStore { ... bool isScoped_; ... If its not going to be a key word, I would still like to have the facility optimized, and if allocating a class on the stack is out, I would redesign and use a struct. Not all patterns may be fully checkable at compile time. Might as well ask if any particular program halts. Use with caution. A language is not complete if you cannot hang yourself with it. I did not like putting this as a class property. scope class RigidStore { } I have difficulty finding online any clear statement of intent, rationale, extent, probability or time frame of removal of the keyword. We must be still in the experimental can do everything with templates phase. There are hints on the news group, but an update central documentation of future directions. For instance there is a "Future Directions" URL in the sidebar menu that has not changed for years, mentions template inheritance, array operations, without details. At face value its very un- impressive, looks like a web page that was bookmarked and then never worked on. There is a more comprehensive D2.0 enhancements, that describes Core language changes, but does not mention scope storage. It would be good as a community to have the changers publish, explain rumours of oncoming changes better. External communication should explicate some things, since the internal brain modules of our changes are pressured to communicate and think more, and I can adjust my future expectations. Michael.