www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Error: variable foo conflicts with struct foo

reply Stijn <stijn.herreman telenet.be> writes:
Why is it not allowed for a variable name to match a type name? 
The following example fails with "Error: variable foo conflicts 
with struct foo"

     struct foo {}
     foo foo;
Jan 04
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Thursday, 4 January 2018 at 17:45:35 UTC, Stijn wrote:
 Why is it not allowed for a variable name to match a type name? 
 The following example fails with "Error: variable foo conflicts 
 with struct foo"

     struct foo {}
     foo foo;
Imagine if you then tried to write something like alias bar = foo; Or, imagine you placed the above declarations into the module `mymod.d`, and then in a different module wrote import mymod: foo; Which `foo` should these refer to, the type or the variable?
Jan 04
prev sibling parent reply Colin <grogan.colin gmail.com> writes:
On Thursday, 4 January 2018 at 17:45:35 UTC, Stijn wrote:
 Why is it not allowed for a variable name to match a type name? 
 The following example fails with "Error: variable foo conflicts 
 with struct foo"

     struct foo {}
     foo foo;
How can the compiler know which symbol is which symbol if everything has the same name? Standard practice is to capitalise type names and camelCase variable names.
Jan 04
parent Stijn <stijn.herreman telenet.be> writes:
On Thursday, 4 January 2018 at 17:59:55 UTC, Colin wrote:
 How can the compiler know which symbol is which symbol if 
 everything has the same name?

 Standard practice is to capitalise type names and camelCase 
 variable names.
The C# compiler has no trouble understanding code like that, so I was wondering if it is a design decision for the language, or simply something not yet supported by the compiler. I couldn't find any documentation on it either. Perhaps someone can point me to it? I did manage to work around the issue by fully qualifying the type: private __gshared kernel.idt.IDT_register IDT_register; Also, I'm well aware that I'm not following the standard practices regarding naming, but I'm just toying with -betterC so I'm not really concerned about it.
Jan 04