On 5/23/18 7:11 PM, sarn wrote:
On Wednesday, 23 May 2018 at 13:12:57 UTC, Steven Schveighoffer wrote:
On 5/22/18 9:59 PM, sarn wrote:
* Some code uses __dtor as a way to manually run cleanup code on an
object that will be used again. Putting this cleanup code into a
normal method will cause fewer headaches.
Using __dtor is a very bad idea in almost all cases. Putting cleanup
code into a normal function can have some of the same pitfalls,
however (what if you forget to call the super version of the method?).
The only *correct* way to destroy an object is to follow the runtime's
example or call the function directly.
The destructor also has the nice feature of being called when the
struct goes out of scope.
Best advice -- just use destroy on types to clean them up.
Here's an example of what I'm talking about:
https://github.com/dlang/phobos/blob/master/std/signals.d#L230
It's running __dtor manually just to run some code that happens to be in
the destructor. It's obviously not meant to run any other destructors
(at least, the documentation doesn't say "Use this mixin in your object
and then calling disconnectAll() will destroy everything in your object.").
This is a bug. That module is not well-used and has not received a lot
of attention, if you look at the development history, almost all changes
are global style changes.
It's a broken design pattern, but existing code is doing it. (As I
said, I reviewed a lot of D packages, and I don't have time to file bug
reports or PRs for each one.)
Understood. I'll file one for you on this one. It's one thing to have
some random package using an incorrect pattern, it's another thing to
have Phobos doing it.
But this is not necessarily the definition of POD. Generally this
means it has no postblit, and some people may even be expecting such a
thing to have no methods as well. So I'm not sure we want to add such
a definition to the library.
The common case is that some data types can be blitted around as raw
memory without worrying about destructors, postblits, or whatever is
added to the language in future. This is the thing that seems to
matter. (Have you seen any code that needs to care if a struct has
methods? It sounds like a very special case that can still be handled
using current compile-time reflection anyway.)
__traits(isPOD) seems to do the job, and is a lot better than the ad hoc
implementations I've seen. We should encourage people to use it more
often.
From the D spec, POD means a "struct that contains no hidden members,
does not have virtual functions, does not inherit, has no destructor,
and can be initialized and copied via simple bit copies"
https://dlang.org/glossary.html#pod
Which is what __traits(isPOD) requires.
This seems like what everyone should use when looking for POD, I wasn't
aware we had a __traits for it.
-Steve
