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>).

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.

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.

Successor: P2465R0 Standard Library Modules std and std.all (Stephan T. Lavavej, Gabriel dos Reis, Bjarne Stroustrup), see #1115.

2021-10-12 Library Evolution Telecon

P2465R0: Standard Library Modules std and std.all
2021-10-12 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Stephan T Lavavej

Minute Taker: Steve Downey

Start: 2021-10-12 10:09 Pacific

Does this proposal have:

• Examples?
  • Yes.
• Implementation experience?
  • Some.
• Usage experience?
  • No.
• Deployment experience?
  • No.
• Performance considerations?
  • Yes.
• Discussion of prior art?
  • Yes.
• Changes Library Evolution previously requested?
  • Yes.
• Wording?
  • Yes.
• Feature test macro?

Topics to Polls:

• Design options:
  • std:: only module and global only module.
  • std:: only module and std:: + global module.
• Names.

POLL: Provide both
0) a std:: only module, and

1. a std:: + global module
   (what's currently in the paper and preferred by the authors).

Attendance: 30

# of Authors: 3

Author Position: 3 x SF

Outcome: Consensus in favor.

POLL: Provide both
0) a std:: only module, and

1. a global only module.

Attendance: 30

# of Authors: 3

Author Position: 2 x SA, 1 x N

Outcome: No consensus.

POLL: Provide the following standard library modules (vote once):

Attendance: 31

# of Authors: 3

Author Position: 3 x A

Outcome: Option (A) has the stronger consensus.

POLL: The std:: only module should be named std.

Attendance: 31

# of Authors: 3

Author Position: 3 x SF

Outcome: Consensus in favor.

POLL: The std:: + global module should be of the form std.X (where X is a placeholder).

Attendance: 28

# of Authors: 3

Author Position: 3 x SF

Outcome: Weak consensus in favor.

POLL: The std:: + global module should be of the form std_X (where X is a placeholder).

Attendance: 28

# of Authors: 3

Author Position: 1 x WA, 2 x SA

Outcome: Consensus against.

POLL: The std:: + global module should be of the form stdX (where X is a placeholder).

Attendance: 28

# of Authors: 3

Author Position: 1 x WA, 2 x SA

Outcome: No consensus.

SA: I find it harder to read without punctuation in the middle. That's why I
was SA this one, but WA the underscore poll.

POLL: The std:: + global module should be named std.all.

Attendance: 28

# of Authors: 3

Author Position: 3 x SF

Outcome: No consensus.

POLL: The std:: + global module should be named std.compat.

Attendance: 28

# of Authors: 3

Author Position: 1 x N, 2 x WF

Outcome: Consensus in favor.

POLL: Modify P2465R0 (Standard Library Modules std and std.all) by renaming std.all to std.compat, and then send the revised paper to LWG for C++23 with priority B1 (to be confirmed with a Library Evolution electronic poll).

Attendance: 27

# of Authors: 3

Author Position: 3 x SF

Outcome: Consensus in favor.

WA: I don't think std.compat is a good name.

WA & SA: I am against the land grab of std.

End: 11:28

Summary

We reviewed P2465R0 (Standard Library Modules std and std.all), which proposes a minimal form of Standard Library modules.

During our last discussion of this topic, we determined that we wanted a module that only exported the names in std:: (as well as operator new/delete).

Today, we discussed whether we should have a second module which either

• exports all the names in std:: plus global names (e.g. ::fopen), or
• exports only global names (e.g. ::fopen).

We had a preference for first option, a std:: + global module. There was some suggestion that we could have both options, in addition to a std:: only module, but there was no noted support for this.

We also concluded our discussion about how these modules should be named. First, we decided that the std:: only module should be called std.

The naming of the std:: + global module was a bit more complicated. The original proposal was std.all, but some were concerned about having a module with a subordinate name (e.g. std.X) that was a superset of its parent (e.g. std), even though the module name syntax does not express any semantic hierarchy. Underscores as a delimiter were also considered, but some were worried about inconsistencies between std.X modules and std_X modules in the future. An undelimited form, stdX, was also suggested.

Ultimately, we only had consensus for the std.X pattern. We settled on the name std.compat for the std:: plus global module.

Outcome

Library Evolution sends P2465R0 (Standard Library Modules std and std.all), with the guidance below, to LWG, for C++23, classified as a focus (P0592 bucket 1 item). This will be confirmed via a Library Evolution electronic poll.