Last update January 23, 2008

DCP Default Private Imports



Difference (last change) (no other diffs, normal page display)

Deleted: 1d0


Changed: 4c3
STATUS: Implemented Proposal #1 "Default Private Imports", as of DMD 0.163 (July-2006).
STATUS: Implemented Proposal #1 "Default Private Imports", as of DMD 0.163 (July-2006).

Changed: 24c23
* news://news.digitalmars.com:119/e9bcof$1iki$1@digitaldaemon.com ([[link]Archives[url=NOLINK]])
* news://news.digitalmars.com:119/e9bcof$1iki$1@digitaldaemon.com

Changed: 28c27
* news://news.digitalmars.com:119/e1l9u2$1vvv$1@digitaldaemon.com ([[link]Archives[url= http://www.digitalmars.com/d/archives/digitalmars/D/11081.html]])
* news://news.digitalmars.com:119/e1l9u2$1vvv$1@digitaldaemon.com ( Archives)
D Change Proposal - Default Private Imports [IMPLEMENTED]

STATUS: Implemented Proposal #1 "Default Private Imports", as of DMD 0.163 (July-2006).

Background & Terminology

[TODO - Explain the issue, what are private and public imports, the transitiveness of non-private imports, etc.]

Related/See Also:

Proposal #1 Default Private Imports

Status: DISCUSSED, IMPLEMENTED

Note: The following details are dated pre-implementation (DMD 0.163, July-2006).

Description
All import statements which do not have a "protection" attribute should default to private, instead of public.

Main Proposal Thread:

Aditional Discussion: Rationale (PROS)
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.
Also, everything else in D is public by default, and consistency is sometimes better than special case rules, even if those special case rules make some things easier. 
 - Walter

Some counter arguments: Some members do not agree with this view. It is argued that import is conceptualy significantly different the other D declarations:

Rating
Overall rating: The community at large agrees with this proposal. Only Walter is known to oppose it.

Proposal #2 Default Private Everywhere

Status: NOT PROPOSED [I'm mentioning this just for completeness]

Description

The default protection attribute for *any* declaration should be private, and not public.

Proposal #3 Separate the Two Import Notions

Status: ALPHA? NOTDISCUSSED? [FIXME]

Background

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.

Description
Use different language constructs for each of these two import notions, with slighty varying semantics. The first type: 
USES pack.module;
will make accessible in the current namespace the pack.module.* names; This import has no protection attributes, the names go the namespace background, and is allways non-transitive [TODO:explain term above].

The second type: 

MULTIALIAS pack.module;
will make accessible in the current namespace the pack.module.* names; This import can have a protection attribute(which defaults to public), the names go the namespace foreground, and is transitive (because it defines new members of the metatype alias).

Notes: This has some implications in the ImportConflictResolution proposals. They can work toghether but it would have to be further detailed how.

Rationale (PROS)

Hum... better conceptualization?


FrontPage | News | TestPage | MessageBoard | Search | Contributors | Folders | Index | Help | Preferences | Edit

Edit text of this page (date of last change: January 23, 2008 23:01 (diff))