[Issue 9139] New: `destroy` is dangerous and inconsistent
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Mon Dec 10 11:40:29 PST 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9139
Summary: `destroy` is dangerous and inconsistent
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: critical
Priority: P2
Component: druntime
AssignedTo: nobody at puremagic.com
ReportedBy: verylonglogin.reg at gmail.com
--- Comment #0 from Denis Shelomovskij <verylonglogin.reg at gmail.com> 2012-12-10 22:40:28 MSK ---
In our root `object` module we have a function "to reclaim non-memory resources
without compromising memory safety" (yes, its a correct definition as it is
what Andrei said and what it really do).
The problem is that it works not only for classes but also for all other types
and behaves differently for each type.
As an example of the current situation danger consider the following code (an
`std.algorithm.move` implementation):
---
void move(T)(ref T source, ref T target)
in { assert(&source == &target || !pointsTo(source, source)); }
body
{
if (&source == &target) return;
static if (hasElaborateDestructor!T)
destroy(target);
static if (hasElaborateAssign!T || !isAssignable!T)
memcpy(cast(void*) &target, cast(const void*) &source, T.sizeof);
else
target = source;
static if (hasElaborateCopyConstructor!T || hasElaborateDestructor!T)
... // set `source` to its `init` state here
}
---
This code compiles fine. And it looks fine not only for D newbies but also for
rather skilled programmers. It also behaves fine in some cases. But it will do
unpredictable things in other cases.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list