P0581 Standard Library Modules

[brycelelbach]

P0581R1 Standard Library Modules (Marshall Clow, Beman Dawes, Gabriel Dos Reis, Stephan T. Lavavej, Billy O’Neal, Bjarne Stroustrup, Jonathan Wakely)

[brycelelbach]

P0581R1: Standard Library Modules

2020-04-14 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Champion: Gabriel Dos Reis

Minute Taker: Inbal Levi

Start Review: 2020-04 10:04

Options:

• One big module.
• Intermediate-sized modules.
• Fine-grained modules.
• Modules that exactly mirror the existing header structure.
  • Not really under consideration; no one is advocating for this.

We are concerned about the ability to evolve the layering.

What is the distinction between std.fundamentals and std.core.

It will be important to be able to expose a standard library facility from
multiple different modules.

We are not particularly concerned with which module (be it the global module or
a specific one) actually owns specific standard library modules; we are
concerned with what is exported from each standard library module.

Global constructors that may impact the feasibility of one big std module:

• std::cout, etc
• <system_error>?

Would be great to get more concrete data on modules performance:

• How expensive is importing a module?
• Do you only pay for what you use?
• Are big modules feasible from a performance viewpoint?
• Are small modules feasible from a performance viewpoint?

We need more field experience to make decisions.

What do we need to do when modularizing the standard library to support
freestanding?

Open questions:

• Is a single big module feasible?
• Are very-fine grained modules feasible?

Should we define one intermediate-sized module as the "freestanding" module?

POLL: Knowing what we know today, we want a big std module with everything
in it.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
11	13	8	1	0

Attendance: 37

# of Authors: 1

Author Position: SF

That has consensus in favor.

POLL: Knowing what we know today, we want intermediate-sized modules
(similar to but not necessarily those proposed by P0581).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	5	11	10	1

Attendance: 36

# of Authors: 1

Author Position: F

That has no consensus.

POLL: Knowing what we know today, we want fine-grained modules
(std.unique_ptr, std.function, etc).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	11	9	4	1

Attendance: 34

# of Authors: 1

Author Position: SA

That has weak consensus in favor.

End: 11:40

CONSENSUS: Knowing what we know today, Library Evolution:

• Definitely wants one big std module.
• Wants fine-grained modules (std::unique_ptr, std.function, etc).
• Is skeptical about intermediate-sized modules (std.core, std.io, etc).

Library Evolution needs more field experience from real-world usage to inform its decision.

Library Evolution would like to see usage reports and benchmarks evaluating the feasibility of the three options (one big module, intermediate-sized modules, and fine-grained modules).

Once that data is available, bring a revision of P0581 (Standard Library Modules), with the guidance above and additional explanation of the motivation and goals for modularizing the standard library, to Library Evolution for further design review.

[brycelelbach]

Pursuant to mailing list discussions after the 2020-04-14 meeting, I am directing the author of this paper to add a section explaining the motivation and goals for modularizing the standard library.

[ben-craig]

P2172 is an opinion paper on this topic.

P2172 was discussed in the June-23-2020 LEWG Telecon. Minutes are here: https://wiki.edg.com/bin/view/Wg21summer2020/P2172R0

[brycelelbach]

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.