Second of all, calling destructors on a modern GC are extremely costly. Sure, your example implementation of destructors seems simple, but it is only possible in a reference counted garbage collector, which is so primitive as to be nearly useless.

This may be true if you want deterministic finalization, but not if you want dtor support in general. The D garbage collector is a typical mark & sweep GC and incurs no overhead for finalizing objects before the memory is freed.

It's another issue entirely whether dtor support is desirable in a GCed language. First of all, there's the weird restriction of not being able to use any references to GCed memory, because that data may already have been collected by the GC. Then there's the issue that collection is not deterministic. Some have suggested that dtors should only be allowed for "scope" objects, so RAII is supported without the false sense of security that dtors might provide for GCed data, but I think a fair argument could be made either way. Personally, I find dtors to be useful in a GCed language, if only as an insurance policy.

By the way, I believe that C++/CLI (ie. C++ for .NET) will call the dtor of managed C++ objects when they are finalized. And I believe that C# has some kind of dtor feature as well. So D isn't the only language to do this.

Although D apps can call C functions, D code can't directly use C headers files. So relevant declarations much be replicated in D if you want to use C stdlib routines. And since D does not use the C preprocessor, the structure of these headers often needs to change from C to D. So to answer your question, the user doesn't have to hack a new runtime, but they may have to create headers properly declaring the stuff they intend to use.

This process is pretty straightforward and mechanical, but the C preprocessor is sufficiently evil that it would be difficult to automate without creating a full C compiler that outputs D code. And I don't think this is the best approach anyway, since a lot of what's in these C headers isn't even needed for someone intending to use the library. Much of it is there for the library implementation itself.

This was mostly the result of poor POSIX support and a terrible network layer. By the time they'd begun to fix this, BeOS had become a kiosk OS and was no longer available for the PC (if I remember correctly).

I got a new Passport Card and plain old Passport at the same time, and the card had a sleeve while the Passport did not. I wondered whether the jacket of the Passport was lined and could only be scanned when open, but haven't bothered to investigate.