Is C# on the Mac?

Doing that would mean that, for example, all the #defines for constants in the C header file would have to be accessed via a C function. While this would make it much easier to port the D runtime library, it would have a significant deleterious effect on performance, as such could not be constant folded or optimized. This is unacceptable for a high performance systems language.

D does not attempt to use FreeBSD header files on Linux. It does not use C header files at all. The point is, for each system, the C header files have to be translated to D import files. The C header files are different on each system, and so the D import files have to be different to match. If the D import files are correctly ported, the D user won't see any difference any more than the C user would. Any D program can use either read/write or stdio, as D has direct access to any C functions. The D I/O functions try to layer on top of stdio functions so that the programmer can mix and match using D and stdio as he pleases, including interfacing with C routines that use C stdio.

D can directly call C functions. It is not necessary to go through thunks or some interface layer or build a DLL for the C calls. D 2.0 can also directly call global C++ functions and C++ member functions for classes that have single inheritance.

D does have multiple inheritance for interfaces. Given that, template mixins, and the strong aggregation support, it's pretty hard to see what's left that might benefit from MI. But if you really, really must have MI, then C++ is for you.

Although bringing Digital Mars C++ to the Mac and Linux would offer several advantages (such as very fast compilation times) there probably wouldn't be enough customers to justify the expense.

I'm very curious what you think is wrong with D's const correctness and operator overloading. Reference (lvalue) returns were recently added to D 2.0.

D supports mixins which does allow you to aggregate behavior without needing multiple inheritance.

The C header files for stdio on FreeBSD won't work on Linux, either, because implementations are free to innovate on that. Significant parts of implementation specific characteristics are exposed in the standard C header files, and these need to be modified for every platform.

D does not use a text preprocessor. Often what is a standard C interface relies on macros in the standard C header files, which is perfectly standard C conforming. The D interface to the standard library has to look at those macro expansions, and write them as equivalent D declarations. Since the macro expansion text is not specified by the C standard, these all have to be gone through for each port of the D standard library. And yes, they do differ in sometimes dramatic ways. The interface to the D standard library needs to be portable, but that doesn't mean the implementation of that library needs to be portable. Some speedups in the D I/O library are possible, for example, by taking advantage of some linux specific api functions.

So you want to be a programmer? lists several courses and their value for a programming career. Foreign language comes at or near the bottom.