[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #22 from Walter Bright  ---
Alternative implementation:
https://github.com/D-Programming-Language/dmd/pull/5445

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||bhe...@moxiegroup.com

--- Comment #21 from hst...@quickfur.ath.cx ---
*** Issue 15567 has been marked as a duplicate of this issue. ***

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #20 from Steven Schveighoffer  ---
(In reply to Ketmar Dark from comment #19)
> ah, i see, thank you. i really misread the suggesion. still, i like Kenji's
> PR4915 more. ;-) i'd better see "shadowing error", so i can simply rename
> symbols, and don't guess if there is conflict or not.

Yes, thank you Timon for explaining better.

The main reason I see local imports being useful is this:

import somemodule;

void foo()
{
   onlyPlaceSomeModuleIsUsed()
}

Now, one can simply say "wait, somemodule isn't something everyone in the file
needs, just foo. I'll move it inside"

And then it breaks. I'd rather just see it work the same. All you are doing is
saying who has access to somemodule's symbols, and avoid polluting the module
namespace.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #17 from Ketmar Dark  ---
this will pollute module scope with imported symbols.

imagine that i have `mymodule.foo (float v)` function, and defined local `foo
(int v)` function. with your "hidden global import" whenever i'll import
"mymodule", it will add unexpected `foo` overload for the whole code.

also, it breaks "module importing orger doesn't matter" rule.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #18 from timon.g...@gmx.ch ---
(In reply to Ketmar Dark from comment #17)
> this will pollute module scope with imported symbols.
> 
> imagine that i have `mymodule.foo (float v)` function, and defined local
> `foo (int v)` function. with your "hidden global import" whenever i'll
> import "mymodule", it will add unexpected `foo` overload for the whole code.
> 
> also, it breaks "module importing orger doesn't matter" rule.


Those statements are all incorrect, so maybe you misunderstood the suggestion.
The suggestion is that name lookup should behave as if the set of global
imports considered depended on the local scope. The net effect is that imports
never hide each other, but symbols of the current module always hide imported
symbols.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #19 from Ketmar Dark  ---
ah, i see, thank you. i really misread the suggesion. still, i like Kenji's
PR4915 more. ;-) i'd better see "shadowing error", so i can simply rename
symbols, and don't guess if there is conflict or not.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #16 from Steven Schveighoffer  ---
Why can't locally imported symbols work exactly as globally imported symbols,
but only accessible in the given scope? That is:

import std.stdio;
// import std.conv; // line 2
void func(string text) {
import std.conv; // after this, it's like line 2 was included
writeln(text); // because std.conv is imported "globally" it doesn't
   // mask local var.
}
void main() {
// line 2 isn't included inside here, because it wasn't imported.
func("Hello world");
}

To me, the only benefit of using locally imported symbols is to make the
imports implementation details for that function. Having the module just
"import globally" at the right time follows the principle of least surprise
(they work like all other imports).

There's another travesty this would fix. If you import another module that
overloads a function in your current module, you have to *reimport the current
module*. i.e.:

a.d:
module a;

void foo(int a) {}

b.d:
module b;

void foo(string s) {}

void main()
{
   import a;
   import b; // MUST include this
   foo("hi"); // for this to compile
   foo(0);
}

I admit not to knowing how easy/possible this is to do with the current front
end.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Keywords||pull

--- Comment #15 from Kenji Hara k.hara...@gmail.com ---
https://github.com/D-Programming-Language/dmd/pull/4915

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Kenji Hara k.hara...@gmail.com changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|k.hara...@gmail.com

--- Comment #14 from Kenji Hara k.hara...@gmail.com ---
We can resolve the issue by applying some rewriting rule.

void test()
{
import a, b;
import c;

stmt1;

improt d;

stmt2;
}

To:

void test()
{
struct __ImportScope1 { // internal namespace
import a, b;
import c;
}
with (__ImportScope1) {
stmt1;

struct __ImportScope2 { // internal namespace
improt d;
}
with (__ImportScope2) {
stmt2;
}
}
}

After that, we can reuse the symbol shadowing check mechanism on WithStatement.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Sobirari Muhomori dfj1es...@sneakemail.com changed:

   What|Removed |Added

   Keywords||spec
URL||http://dlang.org/module.htm
   ||l

--- Comment #13 from Sobirari Muhomori dfj1es...@sneakemail.com ---
Currently documented to work this way.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

timon.g...@gmx.ch changed:

   What|Removed |Added

 CC||timon.g...@gmx.ch

--- Comment #12 from timon.g...@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.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #10 from hst...@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.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #11 from deadalnix deadal...@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).

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

 CC||and...@erdani.com
   Severity|normal  |critical

--- Comment #6 from Andrei Alexandrescu and...@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.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #7 from hst...@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:
--
--

:-)

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

bearophile_h...@eml.cc changed:

   What|Removed |Added

 CC||bearophile_h...@eml.cc

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

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

deadalnix deadal...@gmail.com changed:

   What|Removed |Added

 CC||deadal...@gmail.com

--- Comment #9 from deadalnix deadal...@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.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

dbr dbugrepor...@gmail.com changed:

   What|Removed |Added

 CC||dbugrepor...@gmail.com

--- Comment #3 from dbr dbugrepor...@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.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

--- Comment #4 from dbr dbugrepor...@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.

--

[Issue 10378] Local imports hide local symbols

[via Digitalmars-d-bugs]

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

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

--

[Issue 10378] Local imports hide local symbols

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10378


Martin Krejcirik m...@krej.cz changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||m...@krej.cz
 Resolution||DUPLICATE


--- Comment #1 from Martin Krejcirik m...@krej.cz 2013-06-16 19:45:23 CEST ---
*** This issue has been marked as a duplicate of issue 7329 ***

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 10378] Local imports hide local symbols

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=10378


Peter Alexander peter.alexander...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |


--- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2013-06-16 
11:44:54 PDT ---
Example was invalid, here's a better one:

string message = Hello, world!;
void main()
{
import std.stdio;
writeln(message);
}

Also, re-opening. This isn't a dupe. The other bug is just that the semantics
are undocumented, not that the behaviour is incorrect. If the current behaviour
is documented then the other bug may be closed, but this bug will still be
present, so they are not the same bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---