On 1/29/15 1:35 PM, Artur Skawina via Digitalmars-d wrote:
On 01/29/15 14:43, Steven Schveighoffer via Digitalmars-d wrote:
I really think D should consider extern(C) functions as not overloadable,
All functions are overloadable in D; ie you can mix C and D overloads
freely; this is a feature. It allows you to extend the C i/f without
adding an extra layer of pointless wrappers. And export a subset of
the D i/f to other C-but-not-D-aware languages. Etc.
I think I may not have expressed clearly, but I meant that C bindings
should not be overloadable with C bindings. Overloading C functions with
D functions is perfectly fine.
and universally binding (i.e. it's not an error to have 2 identical definitions
in separate modules,
External functions with identical signatures and identical mangled
names are obviously not conflicting, so that case does not need to
be an error, yes. But I suspect that, in practice, sticking to just
one declaration is a good idea anyway (the language changes with
every compiler release, so the signatures can easily get out of sync.
eg missing nothrow/@nogc/@return attributes).
In practice, this is more difficult to control. It's so easy to just
throw in a C binding when you need it, especially if you don't know
where an existing binding exists, or there isn't a reasonable central
place to place it.
This is more difficult when you have competing unrelated libraries that
you need to use concurrently. To have one corrupt the other, when they
are exactly the same binding, doesn't make a whole lot of sense.
-Steve
