On Friday, August 24, 2018 4:44:31 PM MDT Dominikus Dittes Scherkl via Digitalmars-d wrote: > You're underestimating the benefits. It's not just to be > eventually slightly faster. It makes @safe versions possible, > this in turn avoids a lot of @trusted calls, so reduces review > effort. It allows also to develop own kernels (for maybe new > hardware) without needing a c-toolchain an it makes D more self > contained. There are certainly more advantages. And if you don't > like it, the c stuff remains there for you to use.
It doesn't reduce the number of @trusted calls at all. Best case, you're talking about using @trusted with syscall instead of a function like stat, and for many of the C functions, it's perfectly reasonable to just mark their bindings as @trusted, eliminating the need to use @trusted yourself entirely. You're not reducing the number of uses of @trusted. All you get out of it is that then you've written the OS code using @system rather than relying on the C programmers to do their job when writing basic OS stuff. You then might catch a problem writing that code that someone writing the same code in C wouldn't have caught as easily, but that's it. You're bypassing a _heavily_ used and tested piece of code written by experts just because you want to be able to have @safe verify it, or because you want to avoid it simply because it's C. And because of the prevalence of pointers to local addresses in such code, there's a pretty good chance that a lot of it will have to be hand-vetted and marked with @trusted anyway instead of being able to take advantage of @safe. And if someone wants to write an OS in D, then fine. They can do it. There's nothing about our current approach that stops them. As I understand it, there have already been a couple of projects to do exactly that, but you're not going to replace the major OSes with D any time soon (or likely ever), and the vast majority of D code is going to be interacting with those OSes - most of which provide their public APIs via C (many via the same POSIX API). By using libc like everyone else, we get to take advantage of that work and work with a more portable API, risking fewer bugs in the process. Right now, we don't have to test all of the bindings in druntime to death, because they're just bindings, and we can rely on the libc guys to have done their job, whereas we would then be doing their jobs if we insisted on bypassing libc. It's a maintenance nightmare for little to no benefit. I don't want to have to deal with it as a maintainer, and I don't want programs that I write to be bypassing libc using a custom implementation just because someone decided that they didn't like the fact that it was in C instead of D. - Jonathan M Davis
