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

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
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

--

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

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |code@dawg.eu
         Resolution|---                         |WONTFIX

--- Comment #2 from Martin Nowak <code@dawg.eu> ---
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.

--

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

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> ---
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.

--

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

Shriramana Sharma <samjnaa@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |---

--- Comment #4 from Shriramana Sharma <samjnaa@gmail.com> ---
(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.

--

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

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

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

John Dougan <jdougan@acm.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jdougan@acm.org

--

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

basile-z <b2.temp@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b2.temp@gmx.com
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=24473

--- Comment #5 from basile-z <b2.temp@gmx.com> ---
I add a reference to a slighly related problem I'd noticed a while back.

--