Bug 453 – When importing modules compiler can not distinguish between directory and file

... It cause problems when there is same name of file as a name of directory. E.g. Directory: doost/program_options/a.d doost/program_options/b.d doost/program_options/c.d doost/program_options.d Program: import doost.program_options; Above cause error, although it is easy to see that I mean file not a directory (AFAIK last part of import is always file). It's quite a basic problem, so I thing it should be corrected in the first place. It causes unnecessary problems when porting code from C++ and disallows creating program directory structure in the way designer wants.

[email protected] wrote: > http://d.puremagic.com/issues/show_bug.cgi?id=453 > > Summary: When importing modules compiler can not distinguish > between directory and file > Product: D > Version: 0.169 > Platform: Other > OS/Version: All > Status: NEW > Severity: normal > Priority: P2 > Component: DMD > AssignedTo: [email protected] > ReportedBy: [email protected] > > > .... > > It cause problems when there is same name of file as a name of directory. > > E.g. Directory: > doost/program_options/a.d > doost/program_options/b.d > doost/program_options/c.d > doost/program_options.d > > Program: > import doost.program_options; > > Above cause error, although it is easy to see that I mean file not a directory > (AFAIK last part of import is always file). > > It's quite a basic problem, so I thing it should be corrected in the first > place. It causes unnecessary problems when porting code from C++ and disallows > creating program directory structure in the way designer wants. > > This has come up many times before, and unless Walter has had a severe change of heart (and some genius insights) it won't be changing. Allowing modules and packages to share a name introduces all manner of namespacing conflicts and ambiguities... effectively, imports break down entirely (particularly if any more naming conflicts occur deeper into the namespacing). -- Chris Nicholson-Sauls

Chris Nicholson-Sauls napisał(a): > [email protected] wrote: >> http://d.puremagic.com/issues/show_bug.cgi?id=453 >> >> Summary: When importing modules compiler can not distinguish >> between directory and file >> Product: D >> Version: 0.169 >> Platform: Other >> OS/Version: All >> Status: NEW >> Severity: normal >> Priority: P2 >> Component: DMD >> AssignedTo: [email protected] >> ReportedBy: [email protected] >> >> >> .... >> >> It cause problems when there is same name of file as a name of directory. >> >> E.g. Directory: >> doost/program_options/a.d >> doost/program_options/b.d >> doost/program_options/c.d >> doost/program_options.d >> >> Program: >> import doost.program_options; >> >> Above cause error, although it is easy to see that I mean file not a >> directory >> (AFAIK last part of import is always file). >> >> It's quite a basic problem, so I thing it should be corrected in the >> first >> place. It causes unnecessary problems when porting code from C++ and >> disallows >> creating program directory structure in the way designer wants. >> >> > > This has come up many times before, and unless Walter has had a severe > change of heart (and some genius insights) it won't be changing. > Allowing modules and packages to share a name introduces all manner of > namespacing conflicts and ambiguities... effectively, imports break down > entirely (particularly if any more naming conflicts occur deeper into > the namespacing). > > -- Chris Nicholson-Sauls I am not trying to enforce anything - maybe it's really not good to include such a feature to compiler - I don't try to solve this problem. But if current status quo must be kept, it should be clearly stated in documentation with short explanation (rationale), as it is quite restrictive. I am writing from the "still newbie" position (only one year looking at D newsgroup), so I am sure that this issue will continuously come back later, when new people will give a try to D Language. Regards Marcin Kuszczak Aarti_pl

Cannot fix because if name were both a module and a directory name, import name; import name.foo; the two uses of name could not be distinguished.

(In reply to comment #3) > Cannot fix because if name were both a module and a directory name, > > import name; > import name.foo; > > the two uses of name could not be distinguished. > Why is that? The documentation states the following: The Identifier preceding the rightmost are the packages that the module is in. The packages correspond to directory names in the source file path. Therefore, I would interpret the first import statement as importing the module name, and the second import statement as importing the module foo in the package name. Can't packages be distinguished from modules?

Walter Bright wrote: > [email protected] wrote: >> Can't packages be distinguished from modules? > > Consider the following: > > int F; > class F { } > > That doesn't work either. Cannot have two identical names in the same > scope mean different things. > > Now consider: > > import name; // name.d > import name.foo; // name\foo.d > > and in the code: > > name.foo.bar; > > is that foo.bar inside name.d, or bar inside name\foo.d? It's not going > to work. I see your point. From my point of view, this is simply another case of symbols conflicting, similar to symbols with the same name imported from different modules. When that happens, the compiler reports the problem, and I have to resolve it. Couldn't the compiler look for name.foo.bar in both name.d and name\foo.d, and report an ambiguity if one exists? For example: dmd main.d name.d name\foo.d main.d(6): Error: name.foo.bar has multiple definitions: foo.bar in name.d(4), and bar in name\foo.d(2) ----- name.d ----- struct F { int bar = 1; } F foo; ----- name\foo.d ----- int bar = 2; ----- main.d ----- import name; import name.foo; void main() { printf(name.foo.bar); }