Re: "scope attribute" vs "scope keyword" vs "scope storage class"
On Wednesday, 5 February 2014 at 11:01:00 UTC, Mike wrote:
Are all these terms ("scope attribute", "scope keyword", and
"scope storage class") referring to the same thing?
"scope keyword" and "scope storage class" stay:
http://dlang.org/function.html#parameters
Although AFAIK it's not yet implemented.
Re: "scope attribute" vs "scope keyword" vs "scope storage class"
On Wednesday, 5 February 2014 at 11:01:00 UTC, Mike wrote:
This article (http://dlang.org/memory.html#raii) mentions a
"scope attribute".
The following section (http://dlang.org/memory.html#stackclass)
mentions a "scope storage class".
This deprecated list
(http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack)
states that the "scope keyword" has been deprecated.
Are all these terms ("scope attribute", "scope keyword", and
"scope storage class") referring to the same thing?
Mike
D documentation has rather incosistent naming for attribute
groups.
- scope classes are deprecated, but usage of scope as storage
class is still legal (it is expected to be a no-op for now)
- scope storage class for function parameters is also accepted as
no-op. For delegates it actually has a meaning. No deprecation.
- scope statement as in scope(exit) was never suggested to be
deprecated.
- scope attribute most likely refers to declaration of scope
classes and this is deprecated with them
Re: "scope attribute" vs "scope keyword" vs "scope storage class"
On Wednesday, 5 February 2014 at 15:43:45 UTC, Dicebot wrote: For delegates it actually has a meaning. No deprecation. It's the same meaning as for scope classes though. And the same unsafety.
Re: "scope attribute" vs "scope keyword" vs "scope storage class"
On Wednesday, 5 February 2014 at 15:43:45 UTC, Dicebot wrote: D documentation has rather incosistent naming for attribute groups. - scope classes are deprecated, but usage of scope as storage class is still legal (it is expected to be a no-op for now) Couldn't "scope" allocating a class on the stack just be considered an optimization that can be applied if the scope storage class become fully implemented? - scope storage class for function parameters is also accepted as no-op. For delegates it actually has a meaning. No deprecation. No-op just because it hasn't been implemented yet, right?
Re: "scope attribute" vs "scope keyword" vs "scope storage class"
On Thursday, 6 February 2014 at 19:01:52 UTC, Brad Anderson wrote: On Wednesday, 5 February 2014 at 15:43:45 UTC, Dicebot wrote: D documentation has rather incosistent naming for attribute groups. - scope classes are deprecated, but usage of scope as storage class is still legal (it is expected to be a no-op for now) Couldn't "scope" allocating a class on the stack just be considered an optimization that can be applied if the scope storage class become fully implemented? I think so. Scope classes were unsafe because of leaking references but if `scope` is actually implemented to assure safety it becomes perfectly valid thing to do. - scope storage class for function parameters is also accepted as no-op. For delegates it actually has a meaning. No deprecation. No-op just because it hasn't been implemented yet, right? Yes. And there is no clear definition either.
Re: "scope attribute" vs "scope keyword" vs "scope storage class"
On Thursday, 6 February 2014 at 22:16:30 UTC, Dicebot wrote: On Thursday, 6 February 2014 at 19:01:52 UTC, Brad Anderson wrote: Couldn't "scope" allocating a class on the stack just be considered an optimization that can be applied if the scope storage class become fully implemented? I think so. Scope classes were unsafe because of leaking references but if `scope` is actually implemented to assure safety it becomes perfectly valid thing to do. If you declare something as scope, it is expected to have its destructor called at the end of the scope. Therefore, this behavior needs to be guaranteed. Theoretically of course, the memory could still be allocated on the heap and freed after destruction (or even just marked as destroyed and letting the GC clean it up), but this will probably not have advantages over stack allocation, except maybe for large objects.
