[Issue 17907] Can't automatically resolve to function with same name as module

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sat Oct 21 10:43:26 UTC 2017


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

Shriramana Sharma <samjnaa at gmail.com> changed:

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

--- Comment #4 from Shriramana Sharma <samjnaa at 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.

--


More information about the Digitalmars-d-bugs mailing list