View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
0000555 | mercury | Feature Request | public | 2022-04-05 12:12 | 2022-04-05 12:12 | ||||||||
Reporter | wangp | ||||||||||||
Assigned To | |||||||||||||
Priority | normal | Severity | minor | Reproducibility | N/A | ||||||||
Status | new | Resolution | open | ||||||||||
Product Version | |||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0000555: do not implicitly import modules imported by ancestor modules | ||||||||||||
Description | We may want to change the submodule visibility rule so that declarations from modules imported by ancestor modules are NOT automatically visible to a submodule. E.g. Module a declares foo, and happens to import io. Module a.b can see foo, but it must import io itself if it wants to use io. This change would reduce unwanted coupling between the parent module and submodule (as described in commit 92438b2ec). It would also allow the compiler to warn about unnecessary imports that currently *might* be required by a submodule. An argument against this change is that since nested submodules are written in the same source file as the parent module, it does seem somewhat natural (in a "block scoping" way) for imports in the parent module to also affect a nested submodule. We would not want to have different visibility rules for nested or separate submodules. May be related to Mantis bug 0000505 | ||||||||||||
Tags | No tags attached. | ||||||||||||
Attached Files |
|
Issue History | |||
Date Modified | Username | Field | Change |
---|---|---|---|
2022-04-05 12:12 | wangp | New Issue |