On 10/15/2015 1:18 AM, Dmitry Olshansky wrote:
On 15-Oct-2015 00:52, Vladimir Panteleev wrote:
For example: usage of named enums. In C, all enums (or #defines) all
live within the name namespace, with a prefix serving as the
disambiguating "namespace", and all are implicitly convertible to each
other. In many places, the bindings use named enums instead, which
provides the advantage of strong typing - if a function accepts a
parameter of a certain enum, you cannot accidentally pass a member of
another enum.
Being a windows developer while I was young (and foolish) I would use
wrong constants in the wrong parameter all the time. Even with some time
passing I had to double check every argument manually. So yes, please -
strong enums are hugely beneficial.
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.
