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

On 1/29/2015 5:43 AM, Steven Schveighoffer wrote:
> Is there a good reason to do it the current way besides
> "that's what C++ does"?

My reason for saying "that's what C++ does" is that in 30 years I've never heard anyone bring it up as a problem. So while we could go about diagnosing such errors, I regard it as a very low priority.

On Tuesday, 27 January 2015 at 18:13:36 UTC, Steven Schveighoffer wrote:e or the other, even though they are the same.
>
> I understand the idea behind keeping the lookup rules consistent. But C lookup rules ARE simple.
>
> I would say if two extern(C) declarations are identical (i.e. same parameter types, same attributes), they don't conflict. What does this break?
>
> -Steve

This extern(C) thing is a bit odd.  With C, you can include as many headers and declare the same function as many times as you want to.  D is breaking this functionality.  However, some may see this as a feature.  Suppose you wanted to optimize where you were declaring your function prototypes by making sure there were no duplications?  In C, I can't think of a way to do this.  In D however, it looks like this would cause an error.

I kinda agree that maybe D should handle it the same way C does, but another thought comes to mind.  Say two libraries declared the same extern(C) function but they used different types or different type qualifiers.  You would have to go to one of the libraries and have them modify their's to be identical to the other right? Well, the difference now is that instead of them normalizing their declarations you can suggest that everyone use the same modules for declaring extern(C) functions.  This may have been impossible to do in an old language but since D is relatively new, this doesn't seem to unreasonable to do. Anyway, just some thoughts...I think this problem may be more complex then it seems.

On 1/29/15 4:38 PM, Walter Bright wrote:
> On 1/29/2015 5:43 AM, Steven Schveighoffer wrote:
>> Is there a good reason to do it the current way besides
>> "that's what C++ does"?
>
> My reason for saying "that's what C++ does" is that in 30 years I've
> never heard anyone bring it up as a problem. So while we could go about
> diagnosing such errors, I regard it as a very low priority.
>

Maybe because that's not how it works in C++ (thought I would test):

lib1.h:
namespace x
{
extern "C" {
    void cfunction();
}
}


lib2.h:
namespace y
{
extern "C" {
    void cfunction();
}
}

main.cpp:
#include "lib1.h"
#include "lib2.h"

using namespace x;
using namespace y;

int main()
{
    x::cfunction(); // OK
    y::cfunction(); // OK
    cfunction();    // OK
    return 0;
}

-Steve

Try cfunction() with different parameter types.

On 1/30/15 6:10 PM, Walter Bright wrote:
> Try cfunction() with different parameter types.

OK, I see that was your point.

But what do you say about C++ supporting what I suggested and D failing in that regard?

-Steve