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.

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

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

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?

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.

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é

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