On Thursday, 15 October 2015 at 08:34:10 UTC, Walter Bright wrote:
I know how tempting it is to "fix" windows headers (or other
operating system headers). We made a decision long ago that
this is not on the agenda of the D project. We simply make the
closest approximation of them possible, and go with that.
Taking on the task of "fixing" headers like that makes us then
responsible for documenting them, being responsible for them,
etc., that is way, way beyond our resources. By sticking with
them the way they are, we simply refer people to the OS vendor
documentation on how they are to be correctly used, for better
or worse.
Also, it means that C code that deals with those APIs is
directly transcribable to D without going through another
translation process.
I agree that they would be better if fixed, but the D project
is not going to do that. If anyone wants to make a set of fixed
windows imports, that's great, but it wouldn't be a part of the
official D release.
All good points.
I'd like to add some:
1. Some new versions of C/C++ Windows headers do define a "strict
mode", which enables additional compile-time checks by using
static typing, e.g. for all the various handle-like types.
2. The changes I had in mind would not change the way you would
write code (and I agree C source compatibility is important and
must be preserved). The "strict mode" mentioned above works in
the same way. Compatibility with the old core.sys.windows.windows
remains the highest priority.
3. This effort is likely going to prevent any third-party D
Windows headers project become popular. Why bother if the headers
in the language's runtime library are "good enough"?
Anyway, since there are supporters of both sides, it seems like
the best course of action here and now is to leave the
declarations as they are. If there is desire for it, we can
improve C-source compatibility or introduce opt-in (enabled by a
version) strict mode checks down the line.
