On Friday, 5 February 2016 at 10:49:50 UTC, Daniel Murphy wrote:
Currently D allows overloading extern(C) declarations, see
https://issues.dlang.org/show_bug.cgi?id=15217
Checking for invalid overloads with non-D linkage is covered
here:
https://issues.dlang.org/show_bug.cgi?id=2789
But neither of these cover overloads that aren't simultaneously
visible.
15217 shows us that this lack of checking, when combined with
D's abundant binary-compatible-but-distinct types, is somewhat
useful.
Apart from some scary ABI hacks there is nothing really
stopping us from enforcing that all non-D function in all
modules included in a single compilation have distinct symbol
names or (at least binary-compatible) matching D parameters.
I think it makes sense (when actually linking to C) to allow
stuff like druntime's creative use of overloads. The signatures
of the two bsd_signal() overloads are compatible (from C's
perspective), so why not?
However, multiple `extern(C)` overloads that differ in the number
or size of arguments should trigger a warning. Signed versus
unsigned or even int versus floating point is more of a gray area.
Overloads with conflicting pointer types should definitely be
allowed, but ideally the compiler would force them to be marked
@system or @trusted, since there is an implied unsafe cast in
there somewhere.
