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