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

P0581 Standard Library Modules #857

Open
brycelelbach opened this issue Mar 30, 2020 · 4 comments
Open

P0581 Standard Library Modules #857

brycelelbach opened this issue Mar 30, 2020 · 4 comments
Labels
B1 - Focus C++26 IS LEWG modular-standard-library needs-revision ready-for-library-evolution-meeting-review

Comments

@brycelelbach
Copy link
Collaborator

@brycelelbach brycelelbach commented Mar 30, 2020

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

@brycelelbach brycelelbach added LEWG C++23 labels Mar 30, 2020
@brycelelbach brycelelbach added this to 2020-04-06 Telecon in Library Evolution Telecons Mar 30, 2020
@brycelelbach brycelelbach moved this from 2020-04-06 Telecon to 2020-04-14 Telecon in Library Evolution Telecons Mar 30, 2020
@jensmaurer jensmaurer added this to the 2020-telecon milestone Apr 6, 2020
@jensmaurer jensmaurer added IS and removed C++23 labels Apr 6, 2020
@brycelelbach brycelelbach added needs-revision and removed IS labels Apr 18, 2020
@brycelelbach
Copy link
Collaborator Author

@brycelelbach brycelelbach commented Apr 18, 2020

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 brycelelbach added tentatively-ready-for-plenary C++23 labels Apr 18, 2020
@brycelelbach
Copy link
Collaborator Author

@brycelelbach brycelelbach commented Apr 18, 2020

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.

@jensmaurer jensmaurer removed this from the 2020-telecon milestone Apr 24, 2020
@brycelelbach brycelelbach added telecon-reviewed and removed tentatively-ready-for-plenary labels May 10, 2020
@ben-craig
Copy link
Collaborator

@ben-craig ben-craig commented Jun 25, 2020

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 brycelelbach added B1 - Focus modular-standard-library IS and removed telecon-reviewed labels Aug 25, 2020
@brycelelbach brycelelbach added ready-for-library-evolution-meeting-review scheduled-for-library-evolution labels Sep 15, 2021
@brycelelbach brycelelbach removed the scheduled-for-library-evolution label Oct 12, 2021
@brycelelbach
Copy link
Collaborator Author

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

@brycelelbach brycelelbach added C++26 and removed C++23 labels Nov 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B1 - Focus C++26 IS LEWG modular-standard-library needs-revision ready-for-library-evolution-meeting-review
Projects
None yet
Development

No branches or pull requests

3 participants