On Tuesday, 8 August 2017 at 05:37:41 UTC, ANtlord wrote:
On Sunday, 6 August 2017 at 15:47:43 UTC, Moritz Maxeiner wrote:
If you use this option, do be aware that this feature has been
> scheduled for future deprecation .
It's likely going to continue working for quite a while
I can't understand. Why is moved a scope allocation to a
library. I'm pretty sure it should be a language feature.
The reason is given at the link under "Rationale":
scope was an unsafe feature. A reference to a scoped class could
easily be returned from a function without errors, which would
make using such an object undefined behavior due to the object
being destroyed after exiting the scope of the function it was
allocated in. To discourage it from general-use but still allow
usage when needed a library solution was implemented.
Note that scope for other usages (e.g. scoped variables) is
unrelated to this feature and will not be deprecated.
Do note that - as Mike pointed out - this rationale does predate
DIP1000 escape analysis and is largely invalidated by it for
Another reason to use the library type is the ability to move the
class object around via std.algorithm.move (if you need such C++
style behaviour); I'm not sure whether scope classes will get
this feature (I have argued for it at the bug report linked to in
my response to Mike), but I wouldn't count on it.