-
Notifications
You must be signed in to change notification settings - Fork 5.5k
Open
Description
In at least four places, the guidelines mention modules as if they were still in the future. Specifically,
- ES.30, Note: In the future, modules are likely to eliminate the need for macros in configuration control.
- SF.4, 2nd Note, last bullet point: full protection and flexibility require modules.
- SF.9, Reason: [Cycles] complicate conversion to use language-supported modules (when they become available).
- SF.10, Enforcement: No really good solution is possible until we have modules.
Appendix B also frames the issue in terms of modules, but I suspect it means that in a more general sense, like translation unit or source file.
Since modules have been approved for about five years, it would be helpful if these were updated to reflect current implementations.
In addition, SF.22 recommends using unnamed (anonymous) namespaces rather than static declarations. However, if you use a C++ module shouldn't declaring an entity in the module without export have the same external effect as using an unnamed namespace?
Metadata
Metadata
Assignees
Labels
No labels