On Tuesday, 30 June 2015 at 13:01:46 UTC, Steven Schveighoffer
wrote:
On 6/26/15 11:38 PM, Brian Schott wrote:
On Saturday, 27 June 2015 at 03:16:35 UTC, rsw0x wrote:
calling destroy on a pointer should either be fixed or be an
error,
that should not be allowed to happen.
Completely agreed. Calling destroy() on a pointer has been
incorrect
EVERY time I've seen it done.
I'd say if you want to see cases where it was done correctly,
change the behavior and watch the complaints come in ;)
Wouldn't destroying the pointer target make an assumption about
ownership?
Consider a struct that contains a pointer:
struct S
{
T *x;
}
destroy's algorithm for this struct is to call destroy on all
of the members, then set to S.init. But what if S is just
*referencing* that T, and doesn't *own* it? Isn't this the
wrong thing to do?
I agree it's inconsistent with class references. How to make it
consistent isn't as easy to decide. For me, it's the class
destruction which is incorrect. Consider that destroy is
consistent with scope destruction for every type except for
classes:
class C {}
struct S {}
{
C c = new C;
S s;
S *s2 = new S;
} // calls s.dtor, does not call c.dtor or s2.dtor
And what about arrays? Should calling destroy on an array call
destroy on all of the elements (it currently doesn't)?
If I were to design destroy from scratch, I'd make destroy, and
destroyRef (which destroys referenced data via pointer or
class).
-Steve
I don't think there's a problem with destroy in the first place.
The problem is that it's being advertised as calling the
destructors:
http://dlang.org/library/object/type_info.destroy.html
http://dlang.org/library/object/destroy.html
The function would need a documentation section itself, since
it's being advertised as a replacement for `delete` and expected
to do the same wherever there's something to read about it.
