-
Notifications
You must be signed in to change notification settings - Fork 92
[Version 10.0] Feature support for file-scoped namespaces #1540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: draft-10
Are you sure you want to change the base?
Conversation
| - The scope of a name defined by an *extern_alias_directive* ([§14.4](namespaces.md#144-extern-alias-directives)) extends over the *using_directive*s, *global_attributes*, and *compilation_unit_body* of its immediately containing *compilation_unit* or *namespace_body*. An *extern_alias_directive* does not contribute any new members to the underlying declaration space. In other words, an *extern_alias_directive* is not transitive, but, rather, affects only the *compilation_unit*, *namespace_body*, and *file_scoped_namespace_declaration* in which it occurs. | ||
| - The scope of a name defined or imported by a *using_directive* ([§14.5](namespaces.md#145-using-directives)) extends over the *global_attributes* and *compilation_unit_body* of the *compilation_unit* or *namespace_body* in which the *using_directive* occurs. A *using_directive* may make zero or more namespace or type names available within a particular *compilation_unit*, *namespace_body*, and *file_scoped_namespace_declaration* but does not contribute any new members to the underlying declaration space. In other words, a *using_directive* is not transitive but rather affects only the *compilation_unit*, *namespace_body*, and *file_scoped_namespace_declaration* in which it occurs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect that eventually there will be a conflict generated by these bullet items. These edits are built on top of the edits for the V9 feature "Top-Level Statements" (see PR #1454). And just an hour ago, I tweaked that PR to include "statement_lists" in two places in these items. Ultimately, this PR will need to remove those bits of text as their inclusion is subsumed by this PR.
| ``` | ||
| The scope of an *extern_alias_directive* extends over the *using_directive*s, *global_attributes* and *namespace_member_declaration*s of its immediately containing *compilation_unit* or *namespace_body*. | ||
| The scope of an *extern_alias_directive* is described in [§7.7.1]( basic-concepts.md#771-general). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, I invoked the spec-writing rule, "Don't say the same thing in two different places!"
| A *using_static_directive* ([§14.5.4](namespaces.md#1454-using-static-directives)) imports the nested types and static members of a type. | ||
|
|
||
| The scope of a *using_directive* extends over the *namespace_member_declarations* of its immediately containing compilation unit or namespace body. The scope of a *using_directive* specifically does not include its peer *using_directive*s. Thus, peer *using_directive*s do not affect each other, and the order in which they are written is insignificant. In contrast, the scope of an *extern_alias_directive* includes the *using_directive*s defined in the same compilation unit or namespace body. | ||
| The scope of a *using_directive* is described in [§7.7.1]( basic-concepts.md#771-general). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here, I invoked the spec-writing rule, "Don't say the same thing in two different places!"
This is Rex's adaptation of the corresponding MS proposal.
This feature allows
as an abbreviation for
As we now have two ways to declare a namespace, different compilation units can use different ways of declaring the same namespace, and we have to make sure the spec allows this. I've attempted to do that, but please read my edits carefully.
Also, I have introduced the grammar rule compilation_unit_body and I have attempted to use it instead of older text, but it's possible it could be used in more cases to make things simpler.