www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Annoying module name / typename conflict

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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. :-(


T

-- 
This is not a sentence.
Apr 02 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 Is there any reason whatsoever that the compiler should resolve 
 "S" to
 the module rather than the struct defined by the eponymous 
 module?

For DMD choosing one or the other is arbitrary. It's a defect of the way the D module system is designed. This problem is _absent_ in the Python module system. Maybe one way to reduce a bit this pain source in the D module system is to forbid name clashes, this means the compiler statically forbids a module "foo" to contain the name "foo".
 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. :-(

In D it's better to give them different names. Like a class "Set" is better to go in a module named "sets". Bye, bearophile
Apr 02 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-03 00:08, 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. :-(

Hmm, I never had the problem and I do that all the time. Maybe it's because I usually have my modules in a package. -- /Jacob Carlborg
Apr 03 2012