-
-
Notifications
You must be signed in to change notification settings - Fork 668
Deprecate class allocators and deallocators #8042
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thanks for your pull request, @JinShil! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
| } | ||
| --- | ||
|
|
||
| For more information see https://dlang.org/deprecate.html#Class%20allocators%20and%20deallocators |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a good idea to point users to alternatives like std.experimental.allocator and other RAII articles.
See also: https://issues.dlang.org/show_bug.cgi?id=18613
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please enumerate specifically which articles I should include and I'll add them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably this page is the best we have at the moment - https://dlang.org/blog/the-gc-series
It doesn't really mention stdx.allocator, so I would probably mentioned that separately.
How about:
Many alternatives for class allocators/deallcators exist, among many is the generic
$(REF make, std,experimental,allocator) and $ (REF dispose, std,experimental,allocator) from the allocator package. For other alternatives, see $(LINK2 https://dlang.org/blog/the-gc-series, the recent article about memory allocation on the DBlog)
(just an idea)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Thanks!
src/dmd/dsymbolsem.d
Outdated
| { | ||
| //printf("NewDeclaration::semantic()\n"); | ||
|
|
||
| // @@@DEPRECATED_2019-05@@@ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We recently switched to using an explicit version, see also dlang/DIPs#108 or dlang/phobos#6286 for an example
ghost
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please don't do this for class allocators. We have recently discovered that they can be used to prevent the usage of new (when marked @disable hence forcing people to use custom phobos-style allocators.
I planned to add this to my user library but forgot to. This user library is now in the project tester so this change would really be embarassing.
For deallocators ok since delete is deprecated.
|
I've added support for the syntax |
ghost
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This new version allows the @disable trick so it's good.
| } | ||
| } | ||
| --- | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new @disable new(); syntax should be mentioned here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
wilzbach
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
|
I'm labeling this as "Vision", as I think it corresponds to item 1 in the stated vision.
While that statement was probably intended largely for documentation, there are two sides to that coin: 1. ensuring the specification documents the implementation, 2. ensuring the code implements the documentation; they are one and the same. Deprecations are updates to the specification. Documenting that something is deprecated without actually implementing said deprecation is to disregard the specification. Moving these deprecations forward is locking down the language, and doing it sooner rather than later avoids problems that crop up when users choose to leverage a deprecated feature in some unexpected way, forcing us to make accomodations later. |
|
@WalterBright @andralex I think your approval for this deprecation is required? |
|
Affirmative. Let's move with deprecation. Thanks. |
|
Windows failure is unrelated -> braddr/d-tester#71 There was one spurious failure on OSX in druntime https://auto-tester.puremagic.com/show-run.ghtml?projectid=1&runid=3098596&isPull=true |
deletewas deprecated in 2.079. Before thedeletekeyword can be removed it will be necessary to also deprecate and remove class allocators and deallocators. They have been planned for deprecation for years; this PR finally puts the deprecation process in motion.See https://dlang.org/deprecate.html#Class%20allocators%20and%20deallocators
dlang.org PR: dlang/dlang.org#2277