On Sunday, 2 May 2021 at 15:41:13 UTC, kdevel wrote:
On Saturday, 1 May 2021 at 16:32:32 UTC, Basile B. wrote:
Hard breakage is not acceptable, even if the goal is to
introduce a more correct behavior.
I still wonder why module names are taken as a candidates for
types and functions in the first place. Isn't there a symbol
table for module names separate from that for type and function
names?
I dont think so. That would lead to special cases in fully
qualified lookups.
Lookups must follow the reverse lexical order of declarations so
an import adds a symbols in the current scope.
BTW during the PR review the problem you encounter [was
anticipated](https://github.com/dlang/dmd/pull/12178#issuecomment-773886263) si I guess you're stuck with [the author answer](https://github.com/dlang/dmd/pull/12178#issuecomment-773902749), i.e "this worked because of a special case".
Again you can still try to get the change turn into a deprecation
first, that'd be legit.
Just checked how things are done in another language where
modules are called “packages”:
I have checked in styx too. This does not work either but for
another reason that D, that is that overloads are explicit,
meaning all names unique in a given scope, so
```styx
§s.sx
unit s;
§u.sx
unit v;
struct s {}
import s;
var s s1;
```
gives
u.sx:8:8: error, symbol `s` already declared line 6
same when the import and the var decls positions are exchanged.
