Re: local import hijacking
V Thu, 14 Jan 2016 14:25:43 + Byron Heads via Digitalmars-d napsáno: > I got burned by this yesterday, this code should not compile > > import std.experimental.logger : trace; > > > void foo() { > import std.net.curl : trace; > trace("hello"); > } > > > void main() { > foo(); > } > > > Not sure if this is a duplicate > https://issues.dlang.org/show_bug.cgi?id=15567 > > > No this is OK, there is no reason to not compile. It is same as: import std.stdio; string trace = "trace"; void foo() { int trace = 7; writeln(trace); } void main() { foo(); writeln(trace); } local symbols can hide global symbols
Re: local import hijacking
On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak wrote: V Thu, 14 Jan 2016 14:25:43 + Byron Heads via Digitalmars-d napsáno: I got burned by this yesterday, this code should not compile import std.experimental.logger : trace; void foo() { import std.net.curl : trace; trace("hello"); } void main() { foo(); } Not sure if this is a duplicate https://issues.dlang.org/show_bug.cgi?id=15567 No this is OK, there is no reason to not compile. It is same as: import std.stdio; string trace = "trace"; void foo() { int trace = 7; writeln(trace); } void main() { foo(); writeln(trace); } local symbols can hide global symbols import std.experimental.logger; void foo() { import std.net.curl; lots of curl calls trace("hello"); .. more curl calls } void main() { foo(); } std.net.curl.CurlException@std\net\curl.d(4033): Couldn't resolve host name on handle 2188398 0x00405F65 0x00405F10 0x0040275B 0x0040259E 0x0040202B 0x00402035 0x004257A7 0x004256A8 0x0041B7FF 0x769F337A in BaseThreadInitThunk 0x77429882 in RtlInitializeExceptionChain 0x77429855 in RtlInitializeExceptionChain This was a 4 hour debug which made it worse as I was adding more trace calls to figure out what was going on. My boss is now on the fence, to many compiler bugs with D, he asked me to switch to Java if I have to deal to many more issues like this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another issue we had) And this awesome stack trace helped me so much to track this issue down...
Re: local import hijacking
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote: On Thursday, 14 January 2016 at 14:36:23 UTC, Daniel Kozak wrote: [...] import std.experimental.logger; void foo() { import std.net.curl; lots of curl calls trace("hello"); .. more curl calls } void main() { foo(); } std.net.curl.CurlException@std\net\curl.d(4033): Couldn't resolve host name on handle 2188398 0x00405F65 0x00405F10 0x0040275B 0x0040259E 0x0040202B 0x00402035 0x004257A7 0x004256A8 0x0041B7FF 0x769F337A in BaseThreadInitThunk 0x77429882 in RtlInitializeExceptionChain 0x77429855 in RtlInitializeExceptionChain This was a 4 hour debug which made it worse as I was adding more trace calls to figure out what was going on. My boss is now on the fence, to many compiler bugs with D, he asked me to switch to Java if I have to deal to many more issues like this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another issue we had) And this awesome stack trace helped me so much to track this issue down... Also why is this not allowed then? import std.stdio; void main() { auto x = "foo"; for(int x = 0; x < 10; ++x) { writeln(x); } } Error: variable x is shadowing variable f335.main.x Shadowing is bad and leads to bugs!
Re: local import hijacking
On 14.01.2016 15:25, Byron Heads wrote: I got burned by this yesterday, this code should not compile import std.experimental.logger : trace; void foo() { import std.net.curl : trace; trace("hello"); } void main() { foo(); } I don't see a problem with that specific code. You're explicitly importing `trace` from std.net.curl, so it can't be surprising that it's called. But change one little detail and this qualifies as hijacking, I think: void foo() { import std.net.curl; /* not mentioning trace */ trace("hello"); } Imagine that std.net.curl didn't have a `trace` function when the code was written. std.experimental.logger.trace would have been called then. When a `trace` function is then added to std.net.curl, the code suddenly calls a different `trace`, without any warning. Hijacking.
Re: local import hijacking
V Thu, 14 Jan 2016 16:17:41 +0100 anonymous via Digitalmars-d napsáno: > On 14.01.2016 15:25, Byron Heads wrote: > > I got burned by this yesterday, this code should not compile > > > > import std.experimental.logger : trace; > > > > > > void foo() { > > import std.net.curl : trace; > > trace("hello"); > > } > > > > > > void main() { > > foo(); > > } > > I don't see a problem with that specific code. You're explicitly > importing `trace` from std.net.curl, so it can't be surprising that > it's called. > > But change one little detail and this qualifies as hijacking, I think: > > > void foo() { > import std.net.curl; /* not mentioning trace */ > trace("hello"); > } > > > Imagine that std.net.curl didn't have a `trace` function when the > code was written. std.experimental.logger.trace would have been > called then. When a `trace` function is then added to std.net.curl, > the code suddenly calls a different `trace`, without any warning. > Hijacking. Using local imports is dangerous. It should be used only with selective imports
Re: local import hijacking
On 01/14/2016 10:17 AM, anonymous wrote: On 14.01.2016 15:25, Byron Heads wrote: I got burned by this yesterday, this code should not compile import std.experimental.logger : trace; void foo() { import std.net.curl : trace; trace("hello"); } void main() { foo(); } I don't see a problem with that specific code. You're explicitly importing `trace` from std.net.curl, so it can't be surprising that it's called. But change one little detail and this qualifies as hijacking, I think: void foo() { import std.net.curl; /* not mentioning trace */ trace("hello"); } Imagine that std.net.curl didn't have a `trace` function when the code was written. std.experimental.logger.trace would have been called then. When a `trace` function is then added to std.net.curl, the code suddenly calls a different `trace`, without any warning. Hijacking. Yes, this needs to be fixed. -- Andrei
Re: local import hijacking
On 01/14/2016 09:36 AM, Daniel Kozak via Digitalmars-d wrote: V Thu, 14 Jan 2016 14:25:43 + Byron Heads via Digitalmars-d napsáno: I got burned by this yesterday, this code should not compile import std.experimental.logger : trace; void foo() { import std.net.curl : trace; trace("hello"); } void main() { foo(); } Not sure if this is a duplicate https://issues.dlang.org/show_bug.cgi?id=15567 No this is OK, there is no reason to not compile. It is same as: import std.stdio; string trace = "trace"; void foo() { int trace = 7; writeln(trace); } void main() { foo(); writeln(trace); } local symbols can hide global symbols Correct. The implicitly introduced locals are the problem. Can anyone on the compiler team work on this? -- Andrei
Re: local import hijacking
On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu via Digitalmars-d wrote: [...] > Yes, this needs to be fixed. -- Andrei This issue has been known for a long time: https://issues.dlang.org/show_bug.cgi?id=10378 Kenji even has a PR for it. My favorite blatant demonstration of its nastiness: import std.stdio; void func(string text) { import std.conv; writeln(text); } void main() { func("Hello world"); } Program output: (blank) T -- Жил-был король когда-то, при нём блоха жила.
Re: local import hijacking
On Thursday, 14 January 2016 at 16:32:38 UTC, H. S. Teoh wrote: On Thu, Jan 14, 2016 at 11:09:29AM -0500, Andrei Alexandrescu via Digitalmars-d wrote: [...] Yes, this needs to be fixed. -- Andrei This issue has been known for a long time: https://issues.dlang.org/show_bug.cgi?id=10378 Kenji even has a PR for it. My favorite blatant demonstration of its nastiness: import std.stdio; void func(string text) { import std.conv; writeln(text); } void main() { func("Hello world"); } Program output: (blank) T Wow, can't believe his PR has been sitting unreviewed for 5 months: https://github.com/D-Programming-Language/dmd/pull/4915
Re: local import hijacking
On 01/14/2016 02:10 PM, Joakim wrote: Wow, can't believe his PR has been sitting unreviewed for 5 months: https://github.com/D-Programming-Language/dmd/pull/4915 I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei
Re: local import hijacking
On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote: std.net.curl.CurlException@std\net\curl.d(4033): Couldn't resolve host name on handle 2188398 0x00405F65 0x00405F10 0x0040275B 0x0040259E 0x0040202B 0x00402035 0x004257A7 0x004256A8 0x0041B7FF 0x769F337A in BaseThreadInitThunk 0x77429882 in RtlInitializeExceptionChain 0x77429855 in RtlInitializeExceptionChain This was a 4 hour debug which made it worse as I was adding more trace calls to figure out what was going on. My boss is now on the fence, to many compiler bugs with D, he asked me to switch to Java if I have to deal to many more issues like this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another issue we had) And this awesome stack trace helped me so much to track this issue down... What compiler are you using? The useless stack traces got fixed in a fairly recent version of DMD - as have many, many other issues which are still present in GDC, whose front end is several versions out-of-date. It is recommended to do your testing with DMD because of issues like this, and mostly use GDC for making optimized release builds. Alternately, if you don't want to mix two compilers like that, LDC has good performance and is currently significantly more up-to-date than GDC. Or, you could even just use DMD, as the performance of its generated binaries has improved a whole lot in the past two releases, although it is of course still not as good as GDC or LDC in this respect. More generally, though, much as we might not like to admit it, D2 is still beta quality software. It is *vastly* more stable and less frustrating to work with than it was a few years ago when I first tried it, but it still has a long way to go before compiler problems cease to be a part of normal day-to-day usage. If that's not acceptable to you or your business, you really probably should just use something else and check back in five years or so...
Re: local import hijacking
On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: > On 01/14/2016 02:10 PM, Joakim wrote: > >Wow, can't believe his PR has been sitting unreviewed for 5 months: > > > >https://github.com/D-Programming-Language/dmd/pull/4915 > > I notice Kenji has been absent for a while, could anyone take over > that PR? -- Andrei It's almost an entire month since he suddenly went silent. Completely silent, in fact -- no activity whatsoever on his github account. Is he OK?? T -- Unix is my IDE. -- Justin Whear
Re: local import hijacking
On Thu, 2016-01-14 at 21:36 +, tsbockman via Digitalmars-d wrote: > […] > The useless stack traces got fixed in a fairly recent version of > DMD - as have many, many other issues which are still present in > GDC, whose front end is several versions out-of-date. "several versions behind" might be a better way if putting this. The release cycles of DMD (basically unconstrained), LDC (basically unconstrained), and GDC (heavily constrained), mean that "out of date" is a bad marketing phrase. Especially… > It is recommended to do your testing with DMD because of issues > like this, and mostly use GDC for making optimized release builds. …given this. Clearly the D community needs to try and ensure that each GCC bundle release has teh latest possible D in it, but we must also be positive about which version each compiler supports. > Alternately, if you don't want to mix two compilers like that, > LDC has good performance and is currently significantly more > up-to-date than GDC. Or, you could even just use DMD, as the > performance of its generated binaries has improved a whole lot in > the past two releases, although it is of course still not as good > as GDC or LDC in this respect. > > More generally, though, much as we might not like to admit it, D2 > is still beta quality software. It is *vastly* more stable and > less frustrating to work with than it was a few years ago when I > first tried it, but it still has a long way to go before compiler > problems cease to be a part of normal day-to-day usage. > > If that's not acceptable to you or your business, you really > probably should just use something else and check back in five > years or so... I find this the wrong view of progress, yet one that remains embedded in far too many organizations. It comes in two parts: 1. If a product has changed at all in the last six months, other than trivial bug fixes, it isn't stable enough to use in production. 2. Once we have stuff out in production, nothing may be changed until end of life. Clearly the opposite extreme of "we must use the very latest of every early-access version we can get out hands on" is equally dangerous in production. There is a middle ground. Keep everything as up to date with formally released versions as possible, taking on a continuous change and evolution strategy. In this mindset D is certainly stable enough for production, it is not beta software. DMD is the playground compiler, GDC the conservative but solid one, and LDC the core production tool. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: local import hijacking
On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > In this mindset D is certainly stable enough for production, it is not > beta software. DMD is the playground compiler, GDC the conservative but > solid one, and LDC the core production tool. > > -- > Russel. > Thanks for putting it so eloquently, Russell. Iain.
Re: local import hijacking
Am Thu, 14 Jan 2016 21:36:01 + schrieb tsbockman : > On Thursday, 14 January 2016 at 14:56:39 UTC, Byron Heads wrote: > > std.net.curl.CurlException@std\net\curl.d(4033): Couldn't > > resolve host name on handle 2188398 > > > > 0x00405F65 > > 0x00405F10 > > 0x0040275B > > 0x0040259E > > 0x0040202B > > 0x00402035 > > 0x004257A7 > > 0x004256A8 > > 0x0041B7FF > > 0x769F337A in BaseThreadInitThunk > > 0x77429882 in RtlInitializeExceptionChain > > 0x77429855 in RtlInitializeExceptionChain > > > > This was a 4 hour debug which made it worse as I was adding > > more trace calls to figure out what was going on. My boss is > > now on the fence, to many compiler bugs with D, he asked me to > > switch to Java if I have to deal to many more issues like > > this.. (https://issues.dlang.org/show_bug.cgi?id=15457 another > > issue we had) > > > > And this awesome stack trace helped me so much to track this > > issue down... > > What compiler are you using? > > The useless stack traces got fixed in a fairly recent version of > DMD - as have many, many other issues which are still present in > GDC, whose front end is several versions out-of-date. I'm not sure why you even think the OP is using GDC. His bug report says he's on windows 10. GDC is not supported on windows systems and won't work for anything but trivial programs. And stack traces is one thing GDC has had proper support way before DMD. We have proper stack traces since June 2013: https://github.com/D-Programming-GDC/GDC/pull/65 https://github.com/D-Programming-GDC/GDC/commit/fbde3698398f85768bcf918a7a777d81fd0ac3ed
Re: local import hijacking
On Friday, 15 January 2016 at 09:05:27 UTC, Johannes Pfau wrote: I'm not sure why you even think the OP is using GDC. His bug report says he's on windows 10. GDC is not supported on windows systems and won't work for anything but trivial programs. And stack traces is one thing GDC has had proper support way before DMD. We have proper stack traces since June 2013: https://github.com/D-Programming-GDC/GDC/pull/65 https://github.com/D-Programming-GDC/GDC/commit/fbde3698398f85768bcf918a7a777d81fd0ac3ed Good to know. I was really trying to ask what front-end version he's using, though.
Re: local import hijacking
On Friday, 15 January 2016 at 08:12:03 UTC, Russel Winder wrote: "several versions behind" might be a better way if putting this. The release cycles of DMD (basically unconstrained), LDC (basically unconstrained), and GDC (heavily constrained), mean that "out of date" is a bad marketing phrase. I wasn't trying to market D; I was simply offering my advice to the OP. I think D is a fantastic language, but I'm not going to downplay what I perceive to be its shortcomings. I find this the wrong view of progress, yet one that remains embedded in far too many organizations. It comes in two parts: 1. If a product has changed at all in the last six months, other than trivial bug fixes, it isn't stable enough to use in production. 2. Once we have stuff out in production, nothing may be changed until end of life. Clearly the opposite extreme of "we must use the very latest of every early-access version we can get out hands on" is equally dangerous in production. There is a middle ground. Keep everything as up to date with formally released versions as possible, taking on a continuous change and evolution strategy. In this mindset D is certainly stable enough for production, it is not beta software. DMD is the playground compiler, GDC the conservative but solid one, and LDC the core production tool. That is not my mindset. I consider D beta-quality because whenever I program in D, I encounter bugs (both new and old) in the compiler and/or standard library on almost a daily basis. This has not been my experience with other languages that have more money behind them, like Java (never hit a bug in my life, that I'm aware of), C# (once?), or C++ (so byzantine that I'm not sure I would notice - that's why I prefer D :-) ). None of the bugs I've hit recently has been too difficult to diagnose and work around, which is why I no longer consider D alpha-quality. I, personally, would be comfortable using D in production - but that's because I have a high tolerance for the kinds of minor issues beta software brings with it; not everyone does. And to be clear - I think GDC is awesome. But I also think that someone with a low tolerance for issues like the one the OP complained about will be happier using DMD or LDC, as I find the newer front-ends noticeably less buggy in day-to-day use. Horses for courses.
Re: local import hijacking
On Friday, 15 January 2016 at 08:15:50 UTC, Iain Buclaw wrote: On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: In this mindset D is certainly stable enough for production, it is not beta software. DMD is the playground compiler, GDC the conservative but solid one, and LDC the core production tool. -- Russel. Thanks for putting it so eloquently, Russell. Iain. The difficulty is that gdc includes a lot of long-standing bugs that are fixed upstream.
Re: local import hijacking
On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei Alexandrescu wrote: On 01/14/2016 02:10 PM, Joakim wrote: Wow, can't believe his PR has been sitting unreviewed for 5 months: https://github.com/D-Programming-Language/dmd/pull/4915 I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei We're live! Please review: https://github.com/D-Programming-Language/dmd/pull/5353
Re: local import hijacking
On Friday, 15 January 2016 at 23:57:51 UTC, Meta wrote: On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei Alexandrescu wrote: On 01/14/2016 02:10 PM, Joakim wrote: Wow, can't believe his PR has been sitting unreviewed for 5 months: https://github.com/D-Programming-Language/dmd/pull/4915 I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei We're live! Please review: https://github.com/D-Programming-Language/dmd/pull/5353 And the build is failing on DAutoTest with nasty assert errors. It built fine for me locally, anyone know what might be the problem?
Re: local import hijacking
On Saturday, 16 January 2016 at 00:03:31 UTC, Meta wrote: And the build is failing on DAutoTest with nasty assert errors. It built fine for me locally, anyone know what might be the problem? Error - file 'dimport.d' contains windows line endings at line 1 ... *** [checkwhitespace] Error 1
Re: local import hijacking
On Saturday, 16 January 2016 at 00:07:59 UTC, tsbockman wrote: On Saturday, 16 January 2016 at 00:03:31 UTC, Meta wrote: And the build is failing on DAutoTest with nasty assert errors. It built fine for me locally, anyone know what might be the problem? Error - file 'dimport.d' contains windows line endings at line 1 ... *** [checkwhitespace] Error 1 I'm talking about this: https://travis-ci.org/D-Programming-Language/dmd/jobs/102725760#L342
Re: local import hijacking
On 01/15/2016 06:57 PM, Meta wrote: On Thursday, 14 January 2016 at 20:37:54 UTC, Andrei Alexandrescu wrote: On 01/14/2016 02:10 PM, Joakim wrote: Wow, can't believe his PR has been sitting unreviewed for 5 months: https://github.com/D-Programming-Language/dmd/pull/4915 I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei We're live! Please review: https://github.com/D-Programming-Language/dmd/pull/5353 Thanks! "All checks have failed" -- Andrei
Re: local import hijacking
On Thursday, 14 January 2016 at 15:54:02 UTC, Daniel Kozak wrote: V Thu, 14 Jan 2016 16:17:41 +0100 anonymous via Digitalmars-d napsáno: On 14.01.2016 15:25, Byron Heads wrote: > I got burned by this yesterday, this code should not compile > void foo() { import std.net.curl; /* not mentioning trace */ trace("hello"); } Using local imports is dangerous. It should be used only with selective imports Some of these problems can be avoided when you write good code. Explicit import is allowed but not the best especially when you are just using one or two functions (locally or globally). Same as those who write: class Name { string name; this(string name) { name = name; } } Instead of; class Name { string name; this(string name) { this.name = name; } } Imagine you have; class Name { string realName; this(string name) { a lot of code here... string realName = name . //This will punish you a lot of code here... string finalName = realName ... a lot of code here... realName = finalName; // code maintained for a long time } } Writing good code takes time much like mining diamond.
Re: local import hijacking
On 15 January 2016 at 23:50, John Colvin via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Friday, 15 January 2016 at 08:15:50 UTC, Iain Buclaw wrote: > >> On 15 Jan 2016 9:12 am, "Russel Winder via Digitalmars-d" < >> digitalmars-d@puremagic.com> wrote: >> >>> >>> In this mindset D is certainly stable enough for production, it is not >>> beta software. DMD is the playground compiler, GDC the conservative but >>> solid one, and LDC the core production tool. >>> >>> -- >>> Russel. >>> >>> >> Thanks for putting it so eloquently, Russell. >> >> Iain. >> > > The difficulty is that gdc includes a lot of long-standing bugs that are > fixed upstream. > GDC is rarely a vanilla cut of the version it supports, and no one should be allergic to submitting backports of library or frontend fixes. It is afterall Boost licensed. :-)
Re: local import hijacking
On Saturday, 16 January 2016 at 01:10:21 UTC, Andrei Alexandrescu wrote: We're live! Please review: https://github.com/D-Programming-Language/dmd/pull/5353 Thanks! "All checks have failed" -- Andrei I hoped it would be as simple as rebasing, but either Kenji left that PR unfinished or there's something I'm missing, as it is not working as evidenced by the autotester. I'll close it in lieu of someone more knowledgeable about the compiler fixing it.
Re: local import hijacking
On Thursday, 14 January 2016 at 22:33:51 UTC, H. S. Teoh wrote: On Thu, Jan 14, 2016 at 03:37:54PM -0500, Andrei Alexandrescu via Digitalmars-d wrote: On 01/14/2016 02:10 PM, Joakim wrote: >Wow, can't believe his PR has been sitting unreviewed for 5 >months: > >https://github.com/D-Programming-Language/dmd/pull/4915 I notice Kenji has been absent for a while, could anyone take over that PR? -- Andrei It's almost an entire month since he suddenly went silent. Completely silent, in fact -- no activity whatsoever on his github account. Is he OK?? T Appears he's back, and he rebased the PR. https://github.com/D-Programming-Language/dmd/pull/4915
Re: local import hijacking
On Thursday, 14 January 2016 at 16:10:29 UTC, Andrei Alexandrescu wrote: local symbols can hide global symbols Correct. The implicitly introduced locals are the problem. Can anyone on the compiler team work on this? -- Andrei No, we cannot just jump to anything that pops up on the newsgroup, b/c we would only be jump but no longer work on anything. I've trying to put fixing the whole import system on the agenda for the past 2 releases, but didn't got much feedback. Import issues are constantly breaking code (e.g. http://forum.dlang.org/post/mailman.3708.1453114739.22025.digitalmars-d-annou...@puremagic.com) and cause such troubles during development. I think it's time to dedicate a whole release to work on imports.
Re: local import hijacking
On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote: I think it's time to dedicate a whole release to work on imports. Please do. D is damn lucky that the main problem people think it has is the GC while it's sitting there with a half finished import system.
Re: local import hijacking
On Monday, 18 January 2016 at 13:26:24 UTC, Jack Stouffer wrote: On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote: I think it's time to dedicate a whole release to work on imports. Please do. D is damn lucky that the main problem people think it has is the GC while it's sitting there with a half finished import system. I'm not sure I agree on 'half finished', one of the biggest things D has over C++ is its vastly superior module system. Is there a compiled list of issues?
Re: local import hijacking
On Monday, 18 January 2016 at 13:17:54 UTC, Martin Nowak wrote: On Thursday, 14 January 2016 at 16:10:29 UTC, Andrei Alexandrescu wrote: local symbols can hide global symbols Correct. The implicitly introduced locals are the problem. Can anyone on the compiler team work on this? -- Andrei No, we cannot just jump to anything that pops up on the newsgroup, b/c we would only be jump but no longer work on anything. I've trying to put fixing the whole import system on the agenda for the past 2 releases, but didn't got much feedback. Import issues are constantly breaking code (e.g. http://forum.dlang.org/post/mailman.3708.1453114739.22025.digitalmars-d-annou...@puremagic.com) and cause such troubles during development. I think it's time to dedicate a whole release to work on imports. I tried to simply define imports, and it is way more complex than you'd expect. We probably need some spec first.
Re: local import hijacking
On Monday, 18 January 2016 at 14:01:15 UTC, rsw0x wrote: one of the biggest things D has over C++ is its vastly superior module system. When you compare D's something with C++'s nothing, then the module system in D is infinitely better by definition. Is there a compiled list of issues? 1. As deadalnix pointed out, a lack of spec 2. Issue 313 3. Issue 314 4. Issue 10378 These are the biggest IMO. There are probably others I don't know of. I'm not sure I agree on 'half finished' When looking at the above issues, it becomes clear that the D module system does not completely provide one of the main things module systems are designed for: encapsulation.
Re: local import hijacking
On 01/18/2016 06:02 PM, Jack Stouffer wrote: Is there a compiled list of issues? 1. As deadalnix pointed out, a lack of spec 2. Issue 313 3. Issue 314 4. Issue 10378 These are the biggest IMO. There are probably others I don't know of. https://issues.dlang.org/show_bug.cgi?id=1238
Re: local import hijacking
On Monday, 18 January 2016 at 17:02:07 UTC, Jack Stouffer wrote: On Monday, 18 January 2016 at 14:01:15 UTC, rsw0x wrote: one of the biggest things D has over C++ is its vastly superior module system. When you compare D's something with C++'s nothing, then the module system in D is infinitely better by definition. Is there a compiled list of issues? 1. As deadalnix pointed out, a lack of spec 2. Issue 313 3. Issue 314 4. Issue 10378 These are the biggest IMO. There are probably others I don't know of. I'm not sure I agree on 'half finished' When looking at the above issues, it becomes clear that the D module system does not completely provide one of the main things module systems are designed for: encapsulation. The problem is that D's import system is much more advanced than those in C++ or Java, allowing much more control and precision over what's imported, so some leaks have sprung in D's more complex module implementation. Certainly much more than half, but definitely not finished. :) If you simply stick a bunch of non-selective imports at the top of a module, ie non-local, and all the modules you import do the same (this is tougher, as not everybody is aware of the issue and some library might leak symbols into your module if they're not as conservative), you'll have no problem. If you use more advanced features like selective or local imports, there are a few places they leak symbols or can shadow variables in non-intuitive ways, as the issues you listed enumerate.