• Joakim (16/16) Jan 26 2015 Right now, any attempt to have symbols with the same name errors
• Daniel Kozak (2/18) Jan 26 2015 You can use static import, or alias to solve this issue
• Joakim (8/15) Jan 26 2015 Yep, both seem to be an easier way to fix the compile error.
• Nicholas Wilson (3/19) Jan 26 2015 What you want is pragma Mangle. see http://dlang.org/pragma.html

"Joakim" <dlang joakim.fea.st> writes:

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.

"Daniel Kozak" <kozzi11 gmail.com> writes:

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

"Joakim" <dlang joakim.fea.st> writes:

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.

"Nicholas Wilson" <iamthewilsonator hotmail.com> writes:

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.