[Issue 18517] Import order is not invariant
https://issues.dlang.org/show_bug.cgi?id=18517 --- Comment #5 from Steven Schveighoffer --- I wasn't a part of that conversation, but the "feature" makes no sense -- if you want to import a module and it doesn't reside at the filename that you import, then the system can't find that module. It doesn't make sense that the compiler then "renames" the module after the file name. Is the conversation listed somewhere on github or the forums? I'd like to reopen that conversation. --
[Issue 18517] Import order is not invariant
https://issues.dlang.org/show_bug.cgi?id=18517 --- Comment #4 from Jonathan Marler --- > I would expect that if a module is loaded via using the filesystem, and the > module name doesn't match how it was found, then this should be an error. > Anything else seems to strain your sanity! I thought the same, even made a PR to fix this but was told that by Andrei that Walter didn't want to integrate this restriction. > In other words, if you pass the modules on the command line, then they can > have non-matching filenames, but if they were found via the module name > mapping to directories, they had better match the module name. Agreed, but Walter and Andrei do not. I believe this is the PR I created to enforce this, https://github.com/dlang/dmd/pull/7878/files but Walter and Andrei discussed this on their own and decided against it. The unfortunate consequence is that now no matter what we do, you can get different results if you compile different sets of modules, i.e. dmd -c foo.d bar.d can be different than dmd -c foo.d dmd -c bar.d there's no way to make these behave the same with their decision not to enforce this rule. Seems ludicrous to me but not much I can do when they decide to discuss these things behind close doors. --
[Issue 18517] Import order is not invariant
https://issues.dlang.org/show_bug.cgi?id=18517 --- Comment #3 from Steven Schveighoffer --- Hm... I didn't realize that the module identifier was not identical to the filename. That is interesting. It's not clearly stated in this bug report that this is a requirement to get the error to occur -- I thought it had something to do with the fact that `thing` appears in both files. I would expect that if a module is loaded via using the filesystem, and the module name doesn't match how it was found, then this should be an error. Anything else seems to strain your sanity! In other words, if you pass the modules on the command line, then they can have non-matching filenames, but if they were found via the module name mapping to directories, they had better match the module name. --
[Issue 19341] New: Strange foreach, tupleof, const ref interaction
https://issues.dlang.org/show_bug.cgi?id=19341
Issue ID: 19341
Summary: Strange foreach, tupleof, const ref interaction
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: briancsch...@gmail.com
struct S
{
double a = 0;
double b = 0;
double c = 0;
}
void main()
{
S s;
foreach (const ref mVal; s.tupleof)
{
mVal = 1 / mVal; // mVal is const and this should not work.
}
}
--
[Issue 18517] Import order is not invariant
https://issues.dlang.org/show_bug.cgi?id=18517 --- Comment #2 from Walter Bright --- Jonathan Marler's Relevant Pull Requests: Fix module/import order invariance: https://github.com/dlang/dmd/pull/7900 Interpret imports the same regardless of other modules passed on the command line: https://github.com/dlang/dmd/pull/7878 Add broken import order invariance tests: https://github.com/dlang/dmd/pull/8165 Deprecate import/module name mismatch (ALL CASES): https://github.com/dlang/dmd/pull/7778 --
[Issue 15086] import doesn't verify module declaration
https://issues.dlang.org/show_bug.cgi?id=15086 Walter Bright changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18517 --
[Issue 18517] Import order is not invariant
https://issues.dlang.org/show_bug.cgi?id=18517 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15086 --
[Issue 19339] extern(C++, namespace|string) disables UFCS
https://issues.dlang.org/show_bug.cgi?id=19339 Manu changed: What|Removed |Added CC||turkey...@gmail.com --- Comment #1 from Manu --- Wtf?! That's not okay. --
[Issue 18517] Import order is not invariant
https://issues.dlang.org/show_bug.cgi?id=18517 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com Severity|enhancement |normal --
[Issue 6777] alias this disables casting for classes
https://issues.dlang.org/show_bug.cgi?id=6777 RazvanN changed: What|Removed |Added CC||initrd...@gmail.com --- Comment #14 from RazvanN --- *** Issue 14331 has been marked as a duplicate of this issue. *** --
[Issue 14331] Cannot cast(void*) a class with an alias this struct
https://issues.dlang.org/show_bug.cgi?id=14331 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |DUPLICATE --- Comment #2 from RazvanN --- *** This issue has been marked as a duplicate of issue 6777 *** --
[Issue 16086] Imported function name shadows alias this member
https://issues.dlang.org/show_bug.cgi?id=16086 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #3 from RazvanN --- PR: https://github.com/dlang/dmd/pull/8885 --
[Issue 16082] Can't access alias this member with same name as module
https://issues.dlang.org/show_bug.cgi?id=16082 --- Comment #2 from RazvanN --- Alternate PR: https://github.com/dlang/dmd/pull/8885 --
[Issue 19340] New: Protected module members are supposed to be illegal
https://issues.dlang.org/show_bug.cgi?id=19340
Issue ID: 19340
Summary: Protected module members are supposed to be illegal
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: aldac...@gmail.com
I've marked this as a regression because the docs [1] say:
"protected module members are illegal."
However, the compiler not complain about protected module members:
```
module a;
// This compiles
protected int wrong;
```
```
module b;
import std.stdio;
import a;
int main() { writeln(wrong); }
```
Instead, it gives the deprecation message about visibility:
"Deprecation: a.wrong is not visible from module b"
With -d, it compiles and runs.
[1] https://dlang.org/spec/attribute.html#visibility_attributes
--
[Issue 19339] extern(C++, namespace|string) disables UFCS
https://issues.dlang.org/show_bug.cgi?id=19339 Mathias LANG changed: What|Removed |Added Keywords||C++ --
[Issue 19339] New: extern(C++, namespace|string) disables UFCS
https://issues.dlang.org/show_bug.cgi?id=19339
Issue ID: 19339
Summary: extern(C++, namespace|string) disables UFCS
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pro.mathias.l...@gmail.com
```
extern (C++, std) { void fake_sym (int); }
extern (C++, `std`) { void fake_sym2 (int); }
extern (C++) { void fake_sym3 (int); }
void main () {
42.fake_sym; // Line 5
42.fake_sym2; // Line 6
42.fake_sym3;
}
```
Does not compile for `fake_sym` and `fake_sym2`, but works for the 3rd case:
```
test.d(5): Error: no property fake_sym for type int
test.d(6): Error: no property fake_sym2 for type int
```
Tested with the latest release (v2.081.2) and ~master.
--
