On Sunday, 21 September 2014 at 06:41:25 UTC, Sönke Ludwig wrote:
> There are also funny little things like this one:
> http://dpaste.dzfl.pl/aac84d5ffae8

HAHAHAHA, that is retarded XD

V Sun, 21 Sep 2014 08:41:26 +0200
Sönke Ludwig via Digitalmars-d <digitalmars-d@puremagic.com> napsáno:

> Am 21.09.2014 07:29, schrieb deadalnix:
> > On Friday, 19 September 2014 at 10:59:24 UTC, Dicebot wrote:
> >> Yeah this is exactly what I was asking about. I assumed that deadlnix has done some research about it and found some specific inconsistencies / issues - after all, it is not the only implementation-defined feature he must have encountered :)
> >
> > DMD does very bizarre things. I think I should write a DIP, but time is always running low...
> >
> > Free goodie: when you import, all symbol are resolved via the expected import resolution mechanism. All ? No, the root package is imported in the local scope.
> >
> > foo(int a) {
> >    import a.b.c;
> >    // a is now a package and not the parameter a anymore.
> > }
> 
> There are also funny little things like this one: http://dpaste.dzfl.pl/aac84d5ffae8
> 

Yep, this is reason why I do not use local imports for all symbols. When I need local import of something, then I import just what I really need with alias:

http://dpaste.dzfl.pl/0fe84e060f718

On 09/21/2014 07:29 AM, deadalnix wrote:
>
> Free goodie: when you import, all symbol are resolved via the expected
> import resolution mechanism. All ? No, the root package is imported in
> the local scope.
>
> foo(int a) {
>    import a.b.c;
>    // a is now a package and not the parameter a anymore.
> }

For local imports, DMD imports _all_ symbols into the local scope, shadowing anything that was there, which is plain broken (as Sӧnke's example shows). BTW: how do you suggest to treat the root package? I think importing into the local scope is fine, but the above example should emit an error because the parameter and the package conflict.

(The following code does not compile either:
int std;
import std.conv;)

On Sun, Sep 21, 2014 at 06:49:22AM +0000, deadalnix via Digitalmars-d wrote:
> On Sunday, 21 September 2014 at 06:41:25 UTC, Sönke Ludwig wrote:
> >There are also funny little things like this one: http://dpaste.dzfl.pl/aac84d5ffae8
> 
> HAHAHAHA, that is retarded XD

Wow, that is truly messed up. XD  That's a perfect WAT candidate. :D


T

-- 
Ignorance is bliss... until you suffer the consequences!

On Sun, Sep 21, 2014 at 02:55:47PM +0200, Timon Gehr via Digitalmars-d wrote:
> On 09/21/2014 07:29 AM, deadalnix wrote:
> >
> >Free goodie: when you import, all symbol are resolved via the expected import resolution mechanism. All ? No, the root package is imported in the local scope.
> >
> >foo(int a) {
> >   import a.b.c;
> >   // a is now a package and not the parameter a anymore.
> >}
> 
> For local imports, DMD imports _all_ symbols into the local scope, shadowing anything that was there, which is plain broken (as Sӧnke's example shows).  BTW: how do you suggest to treat the root package? I think importing into the local scope is fine, but the above example should emit an error because the parameter and the package conflict.
> 
> (The following code does not compile either:
> int std;
> import std.conv;)

I also think it's OK to import symbols into the local scope, but I don't think conflicts should cause errors immediately, only when you actually try to reference an ambiguous symbol. I.e., this should work:

	string foo(string text) {
		import std.conv; // includes std.conv.text
		return "";	// but `text` is never referenced
	}

but this should emit an error:

	string foo(string text) {
		import std.conv; // includes std.conv.text
		return text;	// error: parameter `text` conflicts with std.conv.text
	}


T

-- 
In order to understand recursion you must first understand recursion.

On 09/21/2014 03:53 PM, H. S. Teoh via Digitalmars-d wrote:
> I.e., this should work:
>
> 	string foo(string text) {
> 		import std.conv; // includes std.conv.text
> 		return "";	// but `text` is never referenced
> 	}
>
> but this should emit an error:
>
> 	string foo(string text) {
> 		import std.conv; // includes std.conv.text
> 		return text;	// error: parameter `text` conflicts with std.conv.text
> 	}

Why? That's inconsistent with how imports work at module scope. In the second example, 'text' should refer to the parameter.

On 9/21/14, 5:55 AM, Timon Gehr wrote:
> For local imports, DMD imports _all_ symbols into the local scope,
> shadowing anything that was there, which is plain broken (as Sӧnke's
> example shows).

Has this been bugzillized yet? -- Andrei

On Sunday, 21 September 2014 at 15:11:22 UTC, Andrei Alexandrescu
wrote:
> On 9/21/14, 5:55 AM, Timon Gehr wrote:
>> For local imports, DMD imports _all_ symbols into the local scope,
>> shadowing anything that was there, which is plain broken (as Sӧnke's
>> example shows).
>
> Has this been bugzillized yet? -- Andrei

AFAIR it is closely related to famous
https://issues.dlang.org/show_bug.cgi?id=314

On 9/21/2014 5:55 AM, Timon Gehr wrote:
> For local imports, DMD imports _all_ symbols into the local scope, shadowing
> anything that was there, which is plain broken (as Sӧnke's example shows). BTW:
> how do you suggest to treat the root package? I think importing into the local
> scope is fine, but the above example should emit an error because the parameter
> and the package conflict.
>
> (The following code does not compile either:
> int std;
> import std.conv;)

Of course it shouldn't, any more than:

  int std;
  double std;

should compile.

On 09/21/2014 09:54 PM, Walter Bright wrote:
> On 9/21/2014 5:55 AM, Timon Gehr wrote:
>> For local imports, DMD imports _all_ symbols into the local scope,
>> shadowing
>> anything that was there, which is plain broken (as Sӧnke's example
>> shows). BTW:
>> how do you suggest to treat the root package? I think importing into
>> the local
>> scope is fine, but the above example should emit an error because the
>> parameter
>> and the package conflict.
>>
>> (The following code does not compile either:
>> int std;
>> import std.conv;)
>
> Of course it shouldn't, ...

(That was my point.)