extern(C) symbol conflicts

[Steven Schveighoffer via Digitalmars-d]

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