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
Advance deprecation of delete expressions, class allocators, class deallocators: Error #9666
Conversation
Thanks for your pull request and interest in making D better, @JinShil! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. 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. Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + dmd#9666" |
There's also at least one test in druntime that needs to be disabled before this can pass. |
Please elaborate. I replaced |
I'm talking about the unittests in here: https://github.com/dlang/druntime/blob/master/src/rt/lifetime.d which test the implementation of delete. I think they need to be disabled first for this PR to pass. |
Ok, I'll get to it. It looks like this is going to be a much bigger job than I anticipated. It'd probably be a good idea to mark this WIP until I work through all of the issues. |
I'm not a big fan of deprecation or removal of On the other hand, it is quite inconvenient to get the call to GC.free correct. Even experienced D programmers don't know how to do it (see e.g. https://issues.dlang.org/show_bug.cgi?id=13558, also slightly related: https://issues.dlang.org/show_bug.cgi?id=19539). You should not have to know to begin with, as it will lock the user code with the internal implementation. This can be solved by a library function that knows about all the special cases, but I think it should exist before removal. The pair of destroy and delete library functions is unlikely to be accessible to the compiler, while tldr: If |
@rainers: there's __delete in core.memory which is supposed to be a 1:1 replacement of delete. |
Thanks, I didn't know these. And the implementation is just as wrong as in the bug report given above. |
Many of the tests were using |
…s deallocators: Error
Apparently But, I don't know if it's possible to implement class C { ~this() { ++dtor1; } }
{ Object o = new C(); __delete(o); assert(dtor1 == 4); } Since static if (__traits(hasMember, T, "__xdtor"))
obj.__xdtor();
|
You can always try to implement that 😉. |
I'm closing this for now. Removing |
Documentation update: dlang/dlang.org#2631