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 reply "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
parent reply kdevel <kdevel vogtner.de> writes:
On Monday, 2 April 2012 at 22:20:13 UTC, bearophile wrote:

 For DMD choosing one or the other is arbitrary. It's a defect 
 of the way the D module system is designed.
Ran into that problem with a Module S containing module S; import std.stdio; struct S { this (string s) { writeln ("S: " ~ s); } } This code // auto s1 = S("X"); // useS.d(6): Error: function expected before (), not module S of type void would not compile while S s3 = "X"; // OK works. Has this issue been filed in bugzilla?
Jul 16 2017
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 16 July 2017 at 09:01:46 UTC, kdevel wrote:
 On Monday, 2 April 2012 at 22:20:13 UTC, bearophile wrote:

 For DMD choosing one or the other is arbitrary. It's a defect 
 of the way the D module system is designed.
Ran into that problem with a Module S containing module S; import std.stdio; struct S { this (string s) { writeln ("S: " ~ s); } } This code // auto s1 = S("X"); // useS.d(6): Error: function expected before (), not module S of type void would not compile while S s3 = "X"; // OK works. Has this issue been filed in bugzilla?
I hit this one recently and other variations before, a function or local variable name clashing with a struct type name: http://forum.dlang.org/thread/znjmmrdyghhtvypybwvc forum.dlang.org https://github.com/joakim-noah/android/commit/7e35c3ccd3a9d6ea870d39af44d9b11802c17a43 It probably generally has to do with keeping names unique in the symbol namespace because of all the cool stuff you can do interchangeably at compile-time, but I'm not sure how that extends to module names too.
Jul 16 2017
prev sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Sunday, 16 July 2017 at 09:01:46 UTC, kdevel wrote:
 On Monday, 2 April 2012 at 22:20:13 UTC, bearophile wrote:

 For DMD choosing one or the other is arbitrary. It's a defect 
 of the way the D module system is designed.
Ran into that problem with a Module S containing module S; import std.stdio; struct S { this (string s) { writeln ("S: " ~ s); } } This code // auto s1 = S("X"); // useS.d(6): Error: function expected before (), not module S of type void would not compile while S s3 = "X"; // OK works. Has this issue been filed in bugzilla?
You can avoid this issue at all by using lowercase characters in module name only. This is also the offical naming guideline for modules. https://dlang.org/dstyle.html#naming_modules Kind regards André
Jul 16 2017
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 7/16/17 1:32 PM, Andre Pany wrote:
 On Sunday, 16 July 2017 at 09:01:46 UTC, kdevel wrote:
 
 You can avoid this issue at all by using lowercase characters in module 
 name only. This is also the offical naming guideline for modules.
All that is required is that the top-level package is lowercase. Tango had many modules that had upper case module names. But the root package was 'tango'. I would say S as a top-level module is a poor module name, pick something different. -Steve
Jul 17 2017
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