Right now, any attempt to have symbols with the same name errors out, regardless of how they're used.  This caused a problem for me because I'm trying to use a third-party C library that defines a struct type called "socket" and my code calls that library and some networking modules from druntime.  Since core.sys.posix.sys.socket happens to contain a function called socket also, dmd gets confused when I try to create a socket* and use it in my code.

I would think it'd know I can't do that with a function name.  Is such symbol disambiguation a convenience that just isn't implemented yet or something that can't/won't be done?

Right now, I had to go through and selectively import all 14 symbols I needed from the 3 druntime modules that publicly import core.sys.posix.sys.socket, so that the function socket isn't imported.  Seems like a pain that can be mitigated by a smarter compiler.

On Monday, 26 January 2015 at 11:15:26 UTC, Joakim wrote:
> Right now, any attempt to have symbols with the same name errors out, regardless of how they're used.  This caused a problem for me because I'm trying to use a third-party C library that defines a struct type called "socket" and my code calls that library and some networking modules from druntime.  Since core.sys.posix.sys.socket happens to contain a function called socket also, dmd gets confused when I try to create a socket* and use it in my code.
>
> I would think it'd know I can't do that with a function name.  Is such symbol disambiguation a convenience that just isn't implemented yet or something that can't/won't be done?
>
> Right now, I had to go through and selectively import all 14 symbols I needed from the 3 druntime modules that publicly import core.sys.posix.sys.socket, so that the function socket isn't imported.  Seems like a pain that can be mitigated by a smarter compiler.

You can use static import, or alias to solve this issue

On Monday, 26 January 2015 at 11:15:26 UTC, Joakim wrote:
> Right now, any attempt to have symbols with the same name errors out, regardless of how they're used.  This caused a problem for me because I'm trying to use a third-party C library that defines a struct type called "socket" and my code calls that library and some networking modules from druntime.  Since core.sys.posix.sys.socket happens to contain a function called socket also, dmd gets confused when I try to create a socket* and use it in my code.
>
> I would think it'd know I can't do that with a function name.  Is such symbol disambiguation a convenience that just isn't implemented yet or something that can't/won't be done?
>
> Right now, I had to go through and selectively import all 14 symbols I needed from the 3 druntime modules that publicly import core.sys.posix.sys.socket, so that the function socket isn't imported.  Seems like a pain that can be mitigated by a smarter compiler.

What you want is pragma Mangle. see http://dlang.org/pragma.html
this allows you to use the symbol under another name.

On Monday, 26 January 2015 at 11:30:00 UTC, Daniel Kozak wrote:
> On Monday, 26 January 2015 at 11:15:26 UTC, Joakim wrote:
>> Right now, I had to go through and selectively import all 14 symbols I needed from the 3 druntime modules that publicly import core.sys.posix.sys.socket, so that the function socket isn't imported.  Seems like a pain that can be mitigated by a smarter compiler.
>
> You can use static import, or alias to solve this issue

Yep, both seem to be an easier way to fix the compile error.  With the static import, it seemed painful to add the fully scoped path to every symbol from the third-party C library, but I forgot that you can simply use the fully scoped path when invoking the struct type alone, when it's not a static import, so that works.  As for an alias, I didn't think of that, but that also requires the fully scoped path that I had forgotten about.