Skip to content
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

P2412 Minimal module support for the standard library #1082

Closed
wg21bot opened this issue Jul 30, 2021 · 3 comments
Closed

P2412 Minimal module support for the standard library #1082

wg21bot opened this issue Jul 30, 2021 · 3 comments
Labels
B1 - Focus C++23 IS large LEWG modular-standard-library needs-revision
Milestone

Comments

@wg21bot
Copy link
Collaborator

@wg21bot wg21bot commented Jul 30, 2021

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

@wg21bot wg21bot added the info label Jul 30, 2021
@wg21bot wg21bot added this to the 2021-telecon milestone Jul 30, 2021
@cor3ntin cor3ntin added LEWG B1 - Focus ready-for-library-evolution-meeting-review and removed info labels Jul 31, 2021
@brycelelbach brycelelbach added modular-standard-library large C++23 IS scheduled-for-library-evolution labels Aug 1, 2021
@brycelelbach brycelelbach added needs-revision and removed scheduled-for-library-evolution labels Sep 14, 2021
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Sep 14, 2021

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.

@brycelelbach brycelelbach added the scheduled-for-library-evolution label Sep 15, 2021
@jensmaurer
Copy link
Member

@jensmaurer jensmaurer commented Oct 1, 2021

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

@brycelelbach brycelelbach removed ready-for-library-evolution-meeting-review scheduled-for-library-evolution labels Oct 12, 2021
@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Oct 12, 2021

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).
Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
8 8 5 1 0

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.
Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
6 5 5 3 2

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

Option Votes
(A) std:: only and std:: + global 13
(B) std:: only and global only 8

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
7 15 1 0 2

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
6 8 6 3 0

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
0 0 10 9 2

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
4 6 7 5 2

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.

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
3 9 4 5 4

Attendance: 28

# of Authors: 3

Author Position: 3 x SF

Outcome: No consensus.

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
7 10 5 3 0

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

Strongly Favor Weakly Favor Neutral Weakly Against Strongly Against
14 8 0 2 1

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B1 - Focus C++23 IS large LEWG modular-standard-library needs-revision
Projects
None yet
Development

No branches or pull requests

4 participants