www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DMD 2.071.1 and Issue 15925 - [REG 2.071] Import declaration from

reply captaindet <2krnk gmx.net> writes:
the changelog to 2.071.1 lists 15925 as a fixed regression, and
https://issues.dlang.org/show_bug.cgi?id=15925
lists it as "RESOLVED FIXED"

however, the issue as originally submitted still exists in 2.071.1.
so what is going on?

for me as a non-core dev it is difficult to get the gist of the 
discussion on the issue tracker... BUT if it was decided that 15925 is 
INVALID or WONTFIX it must not be marked as RESOLVED FIXED and be 
featured as a fixed regression.

i thought i understood the enforced import rules. but if 15925 is indeed 
invalid, it looks like there had been also changes to the way mixin 
statements (and maybe even mixin expressions?) work. is this explained 
anywhere?

thanks

/det
Jun 29 2016
parent reply qznc <qznc web.de> writes:
On Thursday, 30 June 2016 at 05:42:36 UTC, captaindet wrote:
 the changelog to 2.071.1 lists 15925 as a fixed regression, and
 https://issues.dlang.org/show_bug.cgi?id=15925
 lists it as "RESOLVED FIXED"

 however, the issue as originally submitted still exists in 
 2.071.1.
 so what is going on?

 for me as a non-core dev it is difficult to get the gist of the 
 discussion on the issue tracker... BUT if it was decided that 
 15925 is INVALID or WONTFIX it must not be marked as RESOLVED 
 FIXED and be featured as a fixed regression.

 i thought i understood the enforced import rules. but if 15925 
 is indeed invalid, it looks like there had been also changes to 
 the way mixin statements (and maybe even mixin expressions?) 
 work. is this explained anywhere?
There is a commit [0] with a slightly different test case, where the mixin is in the same module. A second testcase which directly mirrors the issue was reverted [1]. This suggests it is INVALID. I agree that the resolution of the issue is not sufficiently explained. [0] https://github.com/dlang/dmd/commit/ba178e607c33e121142ec15c5064d953fd87a191 [1] https://github.com/dlang/dmd/commit/f0f38381ed27fd8a4d2e36d13623698970cff7bd
Jun 30 2016
parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
Author here. I originally thought the issue was that an 'imported' scope
imports are not considered anymore.
As Walter explained in this issue and in
https://issues.dlang.org/show_bug.cgi?id=15966 this behaviour changed to
prevent hijacking and is intended.
So the only issue left with 15925 was that `-transition=checkimport` did
not warn about it, which Martin fixed. But since the issue was not renamed
/ repurposed, it led to a confusing changelog.

Raised a P.R. : https://github.com/dlang/dlang.org/pull/1404 and renamed
the issue, thanks for reporting.



2016-06-30 9:34 GMT+02:00 qznc via Digitalmars-d <
digitalmars-d puremagic.com>:

 On Thursday, 30 June 2016 at 05:42:36 UTC, captaindet wrote:

 the changelog to 2.071.1 lists 15925 as a fixed regression, and
 https://issues.dlang.org/show_bug.cgi?id=15925
 lists it as "RESOLVED FIXED"

 however, the issue as originally submitted still exists in 2.071.1.
 so what is going on?

 for me as a non-core dev it is difficult to get the gist of the
 discussion on the issue tracker... BUT if it was decided that 15925 is
 INVALID or WONTFIX it must not be marked as RESOLVED FIXED and be featured
 as a fixed regression.

 i thought i understood the enforced import rules. but if 15925 is indeed
 invalid, it looks like there had been also changes to the way mixin
 statements (and maybe even mixin expressions?) work. is this explained
 anywhere?
There is a commit [0] with a slightly different test case, where the mixin is in the same module. A second testcase which directly mirrors the issue was reverted [1]. This suggests it is INVALID. I agree that the resolution of the issue is not sufficiently explained. [0] https://github.com/dlang/dmd/commit/ba178e607c33e121142ec15c5064d953fd87a191 [1] https://github.com/dlang/dmd/commit/f0f38381ed27fd8a4d2e36d13623698970cff7bd
Jun 30 2016
next sibling parent reply qznc <qznc web.de> writes:
On Thursday, 30 June 2016 at 08:08:13 UTC, Mathias Lang wrote:
 Author here. I originally thought the issue was that an 
 'imported' scope
 imports are not considered anymore.
 As Walter explained in this issue and in
 https://issues.dlang.org/show_bug.cgi?id=15966 this behaviour 
 changed to
 prevent hijacking and is intended.
 So the only issue left with 15925 was that 
 `-transition=checkimport` did
 not warn about it, which Martin fixed. But since the issue was 
 not renamed
 / repurposed, it led to a confusing changelog.
I don't see this properly documented [0]. It seems that imports in mixins are not visible even if declared public? This means mixin imports are special? The issue also features a "protected imported". I guess nobody knows what that is supposed to mean? [0] https://dlang.org/spec/module.html#ImportDeclaration
Jun 30 2016
parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-06-30 11:09 GMT+02:00 qznc via Digitalmars-d <
digitalmars-d puremagic.com>:

 I don't see this properly documented [0].

 It seems that imports in mixins are not visible even if declared public?
 This means mixin imports are special?

 The issue also features a "protected imported". I guess nobody knows what
 that is supposed to mean?

 [0] https://dlang.org/spec/module.html#ImportDeclaration
There's an issue for that ( https://issues.dlang.org/show_bug.cgi?id=16004 ) and an associated P.R. ( https://github.com/dlang/dlang.org/pull/1325 ). So far I haven't got any feedback on it. There's not much I can do short of pinging people.
Jun 30 2016
parent qznc <qznc web.de> writes:
On Thursday, 30 June 2016 at 11:40:38 UTC, Mathias Lang wrote:
 2016-06-30 11:09 GMT+02:00 qznc via Digitalmars-d < 
 digitalmars-d puremagic.com>:

 I don't see this properly documented [0].

 It seems that imports in mixins are not visible even if 
 declared public? This means mixin imports are special?

 The issue also features a "protected imported". I guess nobody 
 knows what that is supposed to mean?

 [0] https://dlang.org/spec/module.html#ImportDeclaration
There's an issue for that ( https://issues.dlang.org/show_bug.cgi?id=16004 ) and an associated P.R. ( https://github.com/dlang/dlang.org/pull/1325 ). So far I haven't got any feedback on it. There's not much I can do short of pinging people.
I looked through the PR, but I guess Martin Nowak has to ok it.
Jun 30 2016
prev sibling parent reply captaindet <2krnk gmx.net> writes:
 Author here. I originally thought the issue was that an 'imported' scope
 imports are not considered anymore.
this is exactly what i was/am afraid of ...[see below]
 As Walter explained in this issue and in
 https://issues.dlang.org/show_bug.cgi?id=15966 this behaviour changed to
 prevent hijacking and is intended.
15966 is about "protected" and the very example in 15925 uses a protected import too. not sure about the protected story. the scary thing is that the example in issue 15925 also fails to work if it is a public import inside the mixin template. does this mean mixin templates now have no way of adding imports to the scope they are mixed in? this is really bad news for meta programming. i would have to do this with ugly string mixins from now on, or is this unintended behavior for string mixins as well? or is all this a special case for classes? how about at module level? where is all this mentioned in the specs? this leaves me quite confused.
Jun 30 2016
next sibling parent Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
2016-06-30 14:20 GMT+02:00 captaindet via Digitalmars-d <
digitalmars-d puremagic.com>:
 does this mean mixin templates now have no way of adding imports to the
 scope they are mixed in?
That's exactly what it means. Likewise a base class cannot add an import that will be visible by it's sub classes. string mixin will still work though.
 or is all this a special case for classes? how about at module level?
where is all this mentioned in the specs? What about module level ? I suggest you look at the linked P.R. It should describe the new import behaviour, as well as the new lookup rule (previously underdocumented). If it doesn't address all your questions, feel free to comment on it, so it can benefit everyone.
Jun 30 2016
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 30 June 2016 at 12:20:26 UTC, captaindet wrote:
 this is really bad news for meta programming. i would have to 
 do this with ugly string mixins from now on, or is this 
 unintended behavior for string mixins as well?
No it's not, importing whole modules or packages into the scope of a user of your template is fairly problematic, b/c from there on any change in the imported modules will affect all users. Use selective imports instead to introduce just the necessary steps. In rare cases where the whole module is needed, you can use string mixins. For converting existing code you can use -transition import and/or checkimports.
Jun 30 2016
parent Martin Nowak <code dawg.eu> writes:
On Thursday, 30 June 2016 at 13:05:58 UTC, Martin Nowak wrote:
 Use selective imports instead to introduce just the necessary 
 steps.
s/steps/symbols/
Jun 30 2016