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

dbr <dbugreporter@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dbugreporter@gmail.com

--- Comment #3 from dbr <dbugreporter@gmail.com> ---
The fact that local imports hide things instead of properly detecting conflicts is a dangerous bug. I actually almost trashed a bunch of files because of it since I had something like this:

import std.stdio;
void main() {
    import std.file;    // just wanted to use dirEntries!
    auto files = dirEntries("importantfiles", "*.{png}", SpanMode.depth);
    foreach (f; files) {
        auto hdr = read_header(f.name);
        writeln(f.name, ":");
        writefln("%d x %d", hdr.width, hdr.height);
    }
}

Luckily, I had that read_header call *after* the first writeln, and it of course threw and I only lost one file (and it wasn't actually important). I know (now!) that the docs say this about local (or "scoped") imports: "Imported symbols may hide symbols from outer scopes", but this is damn insane. It's inconsistent and surprising.

--

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

--- Comment #4 from dbr <dbugreporter@gmail.com> ---
Sorry, that writeln(f.name, ":"); was actually writeln(f.name, ":"); as in, it
called std.file.write instead of std.stdio.write as I intended.

--

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

--- Comment #5 from dbr <dbugreporter@gmail.com> ---
I meant write(f.name, ":"); I can't type shit today...

--

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

Andrei Alexandrescu <andrei@erdani.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@erdani.com
           Severity|normal                      |critical

--- Comment #6 from Andrei Alexandrescu <andrei@erdani.com> ---
An example that doesn't compile today for the sake of illustration:

void main(string[] group)
{
    import std.algorithm, std.stdio;
    writeln(group);
}

This is a critical bug. I'm raising it accordingly.

One simple idea (that would nevertheless break existing code): only allow "static import xyz;" and "import xyz : sym1, sym2;" at local scope.

--

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

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #7 from hsteoh@quickfur.ath.cx ---
Most blatant illustration of this bug:
------
import std.stdio;
void func(string text) {
        import std.conv;
        writeln(text);
}
void main() {
        func("Hello world");
}
------

Program output:
------
------

:-)

--

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

bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc

--- Comment #8 from bearophile_hugs@eml.cc ---
I have written some comments here: http://forum.dlang.org/post/wiahdvkvxjnasaijptvi@forum.dlang.org

--

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

deadalnix <deadalnix@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |deadalnix@gmail.com

--- Comment #9 from deadalnix <deadalnix@gmail.com> ---
Proposal:

Free symbol are resolved from the inner scope to the outer scope WITHOUT considering imports. If that lookup fails, the symbol is searched in import from the inner scope to the outer scope.

A variant is to aggregate import into the inner scope.

This solution has various advantages:
 - import cannot hijack in module symbols implicitly.
 - import do not need to be processed if local lookup succeed, and doing less
work is always a way to make the compiler faster.

The main difference between the first proposal and the variant is that that in the first proposal, an inner imported module's symbol can hijack an outer imported one. In the variant, it doesn't happen, but the import lookup phase will be much heavier, as the compiler must look into all imported module at once.

--

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

--- Comment #10 from hsteoh@quickfur.ath.cx ---
@deadalnix: Unfortunately this would require some rather big changes in dmdfe... currently, imports are implemented by actually inserting symbols from the imported module into the symbol table of the current scope. So either we would have to hack the symbol table to mark imported symbols as being imported, and modify symbol lookup to ignore such symbols the first time round; or, we'd have to introduce an additional symbol table per lexical scope for holding imported symbols, alongside the "normal" symbol table.

--

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

--- Comment #11 from deadalnix <deadalnix@gmail.com> ---
(In reply to hsteoh from comment #10)
> @deadalnix: Unfortunately this would require some rather big changes in dmdfe... currently, imports are implemented by actually inserting symbols from the imported module into the symbol table of the current scope. So either we would have to hack the symbol table to mark imported symbols as being imported, and modify symbol lookup to ignore such symbols the first time round; or, we'd have to introduce an additional symbol table per lexical scope for holding imported symbols, alongside the "normal" symbol table.

We have to sell it to Walter as a way to make D compile faster (as it allow for
more lazy imports).

--

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

timon.gehr@gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timon.gehr@gmx.ch

--- Comment #12 from timon.gehr@gmx.ch ---
(In reply to deadalnix from comment #9)
> Proposal:
> 
> Free symbol are resolved from the inner scope to the outer scope WITHOUT considering imports. If that lookup fails, the symbol is searched in import from the inner scope to the outer scope.
> 
> A variant is to aggregate import into the inner scope.
> 
> This solution has various advantages:
>  - import cannot hijack in module symbols implicitly.
>  - import do not need to be processed if local lookup succeed, and doing
> less work is always a way to make the compiler faster.
> 
> The main difference between the first proposal and the variant is that that in the first proposal, an inner imported module's symbol can hijack an outer imported one. In the variant, it doesn't happen, but the import lookup phase will be much heavier, as the compiler must look into all imported module at once.

Another solution would be to not have an a priori precedence order for symbols that are imported and symbols that are found in an enclosing scope, and to then do the usual overload resolution. (Think of this like treating enclosing scopes as imports.) This is more in line with the anti-hijacking design philosophy of the module system.

--