D Change Proposal - Default Private Imports [IMPLEMENTED]
STATUS: Implemented Proposal #1 "Default Private Imports", as of DMD 0.163 (July-2006).
[TODO - Explain the issue, what are private and public imports, the transitiveness of non-private imports, etc.]
- Status: DISCUSSED, IMPLEMENTED
- Note: The following details are dated pre-implementation (DMD 0.163, July-2006).
All import statements which do not have a "protection" attribute should default to private, instead of public.
Main Proposal Thread:
- news://news.digitalmars.com:email@example.com (Subthread, No Archives)
- news://news.digitalmars.com:firstname.lastname@example.org ( Archives)
It is argued that private imports constitute the vast majority of imports in D code, and as such, for the sake of brevity, they should be the default.
Rationale Against (CONS)
It is argued that such change would be inconsistent, since in all other declarations "public" is the default protection level.
Some counter arguments: Some members do not agree with this view. It is argued that import is conceptualy significantly different the other D declarations:
- ( news://news.digitalmars.com:email@example.com)
- ( news://news.digitalmars.com:119/44B409E6.firstname.lastname@example.org)
Overall rating: The community at large agrees with this proposal. Only Walter is known to oppose it.
- BrunoMedeiros: In Favor.
Status: NOT PROPOSED [I'm mentioning this just for completeness]
The default protection attribute for *any* declaration should be private, and not public.
Status: ALPHA? NOTDISCUSSED? [FIXME]
One can think of two separate import notions:
- One, where the imported names are brougth to the current namespace "background" (the "secondary namespace"). Equal names can be imported into the background namespace, and there is a conflict/error only if these names are accessed.
- Two, where the imported names become proper module members, as aliases to their original names/entities. Thus they are brougth to the current namespace "foreground" (the "primary" namespace) and there can be no conflicting names.
Use different language constructs for each of these two import notions, with slighty varying semantics. The first type:
The second type:
Notes: This has some implications in the ImportConflictResolution proposals. They can work toghether but it would have to be further detailed how.
Hum... better conceptualization?