• Stijn (5/5) Jan 04 2018 Why is it not allowed for a variable name to match a type name?
• Paul Backus (7/12) Jan 04 2018 Imagine if you then tried to write something like
• Colin (5/10) Jan 04 2018 How can the compiler know which symbol is which symbol if
• Stijn (12/16) Jan 04 2018 The C# compiler has no trouble understanding code like that, so I

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;

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?

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.

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.


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.