P2412 Minimal module support for the standard library

[wg21bot]

P2412R0 Minimal module support for the standard library (Bjarne Stroustrup)

[brycelelbach]

2021-09-14 Library Evolution Telecon

P2412R0: Minimal Module Support for the Standard Library

2021-09-14 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Bjarne Stroustrup

Minute Taker: Ben Craig

Start: 2021-09-14 10:08 Pacific

Does this proposal have:

• Examples?
  • Yes.
• Implementation experience?
  • Yes (with MSVC); none for a std module that doesn't export anything to the global namespace.
• Usage experience?
  • Some (with MSVC); none for a std module that doesn't export anything to the global namespace.
• Deployment experience?
  • Limited (with MSVC); none for a std module that doesn't export anything to the global namespace.
• Performance considerations?
  • Yes.
• Discussion of prior art?
  • Yes.
• Wording?
  • There's a suggestion of how to start on wording.
  • A champion/wordsmith may be needed to produce wording for this.
• Feature test macro?
  • No, but we should probably have one.

POLL: C++23 should have a module std which exports all the non-macro names in namespace std (and subnamespaces thereof) and operator new/operator delete, including the contents of the C wrapper headers (<cmeow>).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
22	3	0	0	1

Attendance: 26

# of Authors: 1

Author Position: SF

Outcome: Consensus in favor.

SA: I want to reclaim the global namespace and am strongly opposed to this unless it only adds nothing C-ish the global namespace.

POLL: Module std should not export any names in the global namespace except for operator new/operator delete.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
9	7	4	5	0

Attendance: 26

# of Authors: 1

Author Position: WA

Outcome: Weak consensus in favor.

End: 11:31

Summary

At this meeting, we discussed P2412R0, which proposes a minimal form of Standard Library modules. In fact, it proposes just one module - one big std module.

First, the author presented the paper and laid out their rationale and principles for designing Standard Library modules, calling back to prior work such as P0581. The author advocated for introducing one big std module now for C++23, and taking the time needed to plan out finer grained modules and introduce them down the road, either in C++23 or beyond.

The author also presented results that indicated that one big std module is a compile time performance win over #include headers or importing header units with the MSVC compiler. In previous discussions of Standard Library modules, similar results have been shown for Clang's module implementation.

There was a lot of enthusiasm for P2412R0, but we also had a few clarifying discussions.

We talked about whether the contents of the C wrapper headers (<cmeow>) should be a part of the one big std module. We had wide consensus that they should be in the std module.

We had less agreement about whether the std module should be allowed to export entities in the global namespace (excluding operator new/operator delete). Some felt that it was important that the std module continue to expose things like ::sqrt, which people might expect to work. Others felt that we should use this as an opportunity to get a clean slate and avoid carrying along historical baggage and implementation details into the modular Standard Library world. In the end, we had weak consensus in favor of forbidding the std module from exporting names in the global namespace other than operator new/operator delete.

We also briefly discussed the ABI impacts of module ownership. It was suggested that we should add a note to the wording that encourages implementations to prepare for possible migration of std:: entities to different finer grained
modules in the future.

Outcome

Bring a revision of P2412R0 (Minimal Module Support for the Standard Library), with the guidance below, to Library Evolution for further design review.

• Clarify that the C wrapper headers (<cmeow>) should be included in the std module.
• Clarify that the std module should not export any names in the global namespace except for operator new/operator delete.
• Add a non-normative note that encourages implementations to prepare for possible migration of std:: entities to different finer grained modules in the future.
• Add wording.

The authors are strongly encouraged to produce a new revision ASAP; to make C++23, Library Evolution would need to see and forward this proposal before the end of 2021.