digitalmars.D.learn - Why can't functions and struct types have the same name?
- 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
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.
Jan 26 2015
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
Jan 26 2015
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: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.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
Jan 26 2015
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.
Jan 26 2015