Can't automatically resolve to function with same name as module

[dlangBugzillaToGithub]

Shriramana Sharma (@jamadagni) reported this on 2017-10-17T12:16:55Z

Transferred from https://issues.dlang.org/show_bug.cgi?id=17907

CC List

• basile-z
• Martin Nowak (@MartinNowak)
• John Dougan
• RazvanN
• Steven Schveighoffer (@schveiguy)

Description

Compiler does not automatically resolve to function with same name as module:

fun.d:
import std.stdio;
void fun() { writeln("Hello"); }

funmain.d:
import fun;
void main() { fun(); }

$ dmd -offun fun.d funmain.d
funmain.d(2): Error: function expected before (), not module fun of type void

However, in case of struct-s and classes with same name, there is no problem:

str.d:
struct str { int a; }

strmain.d:
import str;
void main() { str var; var.a = 2; }

$ dmd -ofstr str.d strmain.d

cla.d:
class cla { int a; }

clamain.d:
import cla;
void main() { auto var = new cla; var.a = 2; }

$ dmd -ofcla cla.d clamain.d

If it is possible with types, and indeed it is meaningful to name a module after the main type or function defined therein, there seems to be no reason for not being able to resolve to a function with the same name as a module.

Of course, doing `import fun: fun;` will work, but that is unnecessary verbosity and is not being required even now in the case of types as shown above. In D, the compiler is all powerful and can know which resolution of which symbol is appropriate where. The same capability should apply here also.

Thank you!

[dlangBugzillaToGithub]

razvan.nitu1305 commented on 2017-10-20T09:29:35Z

The problem here is that in the first example you are doing symbol resolution while in the second case you are doing type resolution.


Here is what happens in the first case: the generated AST in this case, can be roughly reduced to : IdentifierExp -> CallExp. When semantic is performed on the IdentifierExp node, the symbol "fun" is resolved following these rules [1]. Note that no type check is performed, just plain string comparison, so "fun" is resolved to the import symbol. Later, when semantic is performed on the child node, the CallExp node, the type checks are performed and indeed you cannot call a module declaration as a function, hence the error you receive.

The second case, on the other hand, is doing type resolution, which implicitly checks that the types are equal (through pointer comparison). That is why the second case compiles successfully .

So, by all means the compiler is doing the right thing. Note that calling fun.fun compiles successfully.

I suggest we close this as invalid.

[1] https://dlang.org/spec/module.html#name_lookup

[dlangBugzillaToGithub]

code (@MartinNowak) commented on 2017-10-20T22:04:19Z

Yes, there is little chance to support functions, as the same symbol would need to be resolved differently, e.g. in `.fun.fun` it's the module, but in `.fun()` it's supposed to be the function.
While the type resolution seems inconsistent, it is a common Java idiom to name source files after the main class/type, and it's widely used in (older) D libraries.

[dlangBugzillaToGithub]

schveiguy (@schveiguy) commented on 2017-10-20T22:57:14Z

I'm not recommending to reopen, but just to be clear here, the issue is ONLY a problem with top level packages and modules:

For example:

import std.stdio;

void std() {} // error
void stdio() {} // ok

This limits what you can name your top-level modules and packages, because any time you import something, it defines the symbol in the importing. Public imports don't do this. For example std.stdio publicly imports core.stdc.stdio. But I can define a `core` function in the above example.

I know this is because of the rules, and I know that we want to keep things simple. But consider that any library that defines a top-level module (probably because the library is simple) is invading the namespace of whoever imports it.

It might be worth considering alternatives to how it's currently designed/implemented, if only just for top-level modules/packages.

[dlangBugzillaToGithub]

samjnaa commented on 2017-10-21T10:43:26Z

(In reply to Martin Nowak from comment #2)
> Yes, there is little chance to support functions, as the same symbol would
> need to be resolved differently, e.g. in `.fun.fun` it's the module, but in
> `.fun()` it's supposed to be the function.

Come on people, what is the problem here? When it is followed by a () it is a function, or if it is in another context such as a function argument list where a function is expected then it is a function. Otherwise, it is a module. The compiler, especially the *D* compiler, knows *everything*. It can do this.

> While the type resolution seems inconsistent, it is a common Java idiom to
> name source files after the main class/type, and it's widely used in (older)
> D libraries.

If by this you are saying that you have provided support for types to be named the same as modules because it is the practice so in Java, kindly note that the following Python standard library modules are named the same as their main function:

https://docs.python.org/3/library/bisect.html#bisect.bisect
https://docs.python.org/3/library/copy.html#copy.copy
https://docs.python.org/3/library/fnmatch.html#fnmatch.fnmatch
https://docs.python.org/3/library/getopt.html#getopt.getopt
https://docs.python.org/3/library/getpass.html#getpass.getpass
https://docs.python.org/3/library/gettext.html#gettext.gettext
https://docs.python.org/3/library/glob.html#glob.glob
https://docs.python.org/3/library/pprint.html#pprint.pprint
https://docs.python.org/3/library/select.html#select.select
https://docs.python.org/3/library/signal.html#signal.signal

I can't begin to survey how many third-part Python libraries follow this pattern as well.

Obviously, I'm coming to D after some years in Python for the speed factor. Given that it is technically possible for the D compiler to resolve to a function, marking the bug as WONTFIX seems to be closing one's mind to users' convenience and expectations.

If you aren't able to allot this sufficient priority to spend time on it, at least leave it open until someone can.

[dlangBugzillaToGithub]

b2.temp commented on 2024-10-08T11:06:25Z

I add a reference to a slighly related problem I'd noticed a while back.