You could use a struct on the stack. That has deterministic destruction. You can even have it be refcounted by using std.typecons.RefCounted. Don't use a struct on the heap though if you want to guarantee that the destructor runs. At the moment, I don't think that structs' destructors ever get run if they're put on the heap, because the GC doesn't have the information that it needs to do so (that should be fixed at some point in the future though).
But if you insist on putting it in on the heap in a class, and you want to explicitly destroy the object, then you can call clear on it:
clear(obj);
That will call the object's destructor and then put it in an invalid state, and anything that tries to use it after that should blow up (IIRC, the virtual table gets zeroed out). But the memory isn't actually freed. That's the GC's job. And don't use delete. It's going to be deprecated. I'm actually surprised that it hasn't been yet, since it's been planned for ages to get rid of it.
And of course, one option is to have an explicit function that you call to release the resources. Whether that's a good idea or not depends on what you're doing. But regardless, classes are intended to be collected by the GC and not be freed whenever you choose to.
Work is being done on custom allocators, which would give you more options for how to allocate a class, and one of those would probably allow you to have more deterministic destruction of classes, but that's not ready yet.
And if you're feeling crazy, you can use std.typecons.scoped, which replaces the soon to be deprecated type modifier scope (though scope is sticking around in other contexts - such as scope statements). It puts a class on the stack. But that's unsafe (which is why scope is going away in this context), and you probably might as well just use a struct if you're going to stick the object on the stack.
EDIT: You could also use malloc and free with std.conv.emplace to put the object in a non-GC allocated chunk of memory like you'd have in C++, but I think that you'd have to explicitly call the destructor to get it run, since free doesn't understand about destructors (it being a C function). That would have the advantage of making the memory go away along with the resource (whereas using clear on an object on the GC heap would just destroy the object's contents, not free the memory), but I don't know that that buys you much over using clear on a GC-allocated object.
However, you could then create a free function similar to new which does the malloc and emplace for you, and then have a free function similar to delete which calls the destructor and free, which would give you the same situation as C++. In fact, I wonder if that would be useful enough to make it into the standard library. That's probably the sort of thing that'll end up in the custom allocators though. So, it wouldn't surprise me at all if in the relatively near future, you could use a custom allocator to do something like
auto obj = customAllocObj.create!MyObj(args);
//Do stuff...
customAllocObj.destroy(obj);
And I would think that that would solve your problem fairly well given that that's essentially the same thing that you'd have in C++, just with library functions rather than with the built-in new and delete. I think that I'll bring it up on the newsgroup. I expect that there are at least some folks who would like such a feature, and that does seem to fit in nicely with custom allocators.
