Type safety could prevent nuclear war

[tsbockman via Digitalmars-d]

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.