Annoying module name / typename conflict

[Jonathan M Davis]

On Monday, April 02, 2012 15:08:42 H. S. Teoh wrote:
> Code:
> // S.d
> struct S {
> int x;
> this(int _x) { x = _x; }
> }
> 
> // test.d
> class T {
> S s;
> this(S _s) { s = _s; }
> }
> 
> void main() {
> auto t = new T(S(1)); // this is line 10
> }
> 
> Compiler error:
> 
> test.d(10): Error: function expected before (), not module S of type void
> test.d(10): Error: constructor test.T.this (S _s) is not callable using
> argument types (_error_)
> 
> The error goes away if either struct S or S.d is renamed.
> 
> Is there any reason whatsoever that the compiler should resolve "S" to
> the module rather than the struct defined by the eponymous module?
> 
> Given that in D, private applies per module, it's quite often desirable
> to name the module after the single class/struct that it defines.
> However, this name conflict makes this scheme rather painful to use. :-(

Clearly, it grabs the first thing that it sees which is S, which is the module, 
which does make sense. But given that it makes no sense to use a module in the 
context that you're using S, it wouldn't surprise me if the compiler were 
smart enough to figure out that you meant a different S which _is_ valid in that 
context. I don't know why it isn't. I think that Walter gave a reason for why 
it works this way not too long ago, but I don't recall what it was, and I have 
no idea what thread it was in.

- Jonathan M Davis