On Friday, 23 November 2012 at 21:21:49 UTC, Walter Bright wrote:
On 11/23/2012 5:57 AM, Vladimir Panteleev wrote:
There might be some incompatibilities, for example due to how
the HANDLE type is
declared. In C, you can use either 0 or NULL as a parameter to
a function
accepting an integer or pointer. In D, you cannot. IIRC, some
types were
declared differently in Druntime's modules and in the win32
bindings.
If breaking code were not an issue, the best solution would be
to make HANDLE a
unique, opaque type (like a struct wrapping an intptr_t or
void*) - which is
exactly how it should be treated. It would need to support
assignment/creation
from "null" though.
This is why I don't approve of attempts to "fix" Windows APIs.
It winds up being incompatible here and there, and breaks
things.
I don't think I follow the logic of this argument.
Let's say that Phobos had a templated function that, by mistake,
accepted arguments at compile-time the types of which made no
sense for said function.
Should the bug be fixed, even though it would break compilation
of code most of which used incorrect invocations of that
function? Or should the bug be kept, because fixing it would
break compilation of code that relied on the bug?
If the analogy is invalid, what is the exact problem with
changing HANDLE's type? How much real correct code would break?
How does the inconvenience of forcing users to add a few casts
compare to making it easy to accidentally mix HANDLEs with other
opaque types and pointers in general?
I should point out that some functions (e.g. GlobalLock, IIRC)
take a value, and return the exact same value, but with another
type. This forces the user to use the function as a "gate", lest
they erroneously use the value directly. Using weak typing makes
it too easy to e.g. assign an unlocked memory region to a pointer.
