SG16 plans to review this paper in Belfast with a specific focus on text formatting and if/how Unicode characters not in the basic source character set can be used as unit symbols.

Belfast 2019-11 LEWGI Minutes

P1935R0 Units Library Rationale: Direction Review

Chair: Bryce Adelstein Lelbach

Champion: Mateusz Pusz

Minute Taker: Marco Foco

Start Review: 11-07 8:41

std::chrono is a good litmus test for this feature, as it's an existing part of the library that has a notion of units.

Design goals starting on slide 10.

Priorities: safety > performance > ease of use

POLL: Quantity kind (width, height, etc) should be a priority for the initial release of this feature.

Attendance: 19

# of Authors: 1

Author Position: A

That has consensus against.

POLL: We should promise more committee time to pursuing adding common units (such as SI, customary, etc) to the standard library, knowing that our time is scarce and this will leave less time for other work.

Attendance: 23

# of Authors: 1

Author Position: SF

A: I think only SI will have too small of an audience; I want something extensible.

That has consensus.

POLL: We should promise more committee time to pursuing a standard library framework for user defined units and unit systems, knowing that our time is scarce and this will leave less time for other work.

Attendance: 24

# of Authors: 1

Author Position: SF

A: Afraid the audience that needs this is too small.

SA: Currency is over my dead body.

That has consensus.

POLL: In a C++ standard units framework, C++ conversions should not vary over runtime.

Attendance: 23

# of Authors: 1

Author Position: SF

POLL: We should plan for versioning of standard library physical constants.

Attendance: 23

# of Authors: 0

That has unanimous consent.

POLL: Compile time diagnostics are a Quality-of-Implementation (QOI) matter and should not influence the standard units library API.

Attendance: 23

# of Authors: 1

Authors Position: SA

That has no consensus.

Lunch: 12:00

Resume: 13:35

Minute Taker: Ben Craig

POLL: A standard library of quantity concepts are a priority for the initial release of a standard library units framework.

Attendance: 21

# of Authors: 1

Author Position: SF

A: I voted against because I don't think they should be a priority.

A: I voted against because of compile-time concerns.

That has no consensus.

POLL: We should promise more committee time to pursuing P1935R0 (A C++ Approach to Physical Units), knowing that our time is scarce and this will leave less time for other work.

Attendance: 23

# of Authors: 1

Author Position: SF

SA: Existing practice seems unsettled, unclear but very large scope, worried it obscures precision from my developers, concerns about how it interacts with vectors and matrices.

End: 15:30

CONSENSUS: Bring a revision of P1935R0 (A C++ Approach to Physical Units), with the guidance below, to LEWGI and SG6 for further direction review.

• Remove the proposed standard library quantity concepts.
• Write a separate paper exploring using rational as a CNTTP.
• Explore approaches for versioning standard library physical constants:
  • Version namespaces.
  • Add the version to the identifiers.
  • Template variables parameterized by a tag.
  • WEB's approach (see minutes).

P1935R1 A C++ Approach to Physical Units (Mateusz Pusz)

P1935R2 A C++ Approach to Physical Units (Mateusz Pusz)

Design guidance provided in SG6 on Monday in Prague.

Prague 2020-02 LEWGI Minutes

P1935R3 Physical Units Library: Direction Review

Chair: Bryce Adelstein Lelbach

Champion: Mateusz Pusz

Minute Taker: Ben Craig

Start Review: 2020-02-11 16:00

Design decisions that need to be made:

• How do we create quantities?
• Chrono-like vs constants

Please don't use the term "tony table" in your slides. It's an insider term that has no meaning to new people. Call them "before/after tables"

Prefer named function to explicit constructor to avoid unintentional mismatches.

km, etc could be a constant, but not associated with any value, and thus not with any type. It could have some special type that could be multiplied with values.

POLL: Knowing what we know right now, the design for standard library units must be consistent with std::chrono's interface idioms.

Attendance: 21

# of Authors: 1

Author Position: A

Vincent Reverdy presented his plans for P1930.

End: 17:21

CONSENSUS: Everyone who has a vision for how standard library physical units should collaborate in between meetings and bring either:

• A unified paper from all of you.
• Papers from subsets of you explaining your vision.

Ryan McDougall will chair the inter-meeting discussions of physical units.

SG16 discussed a draft of P1935R1 in Belfast; minutes available here. The following polls were taken:

Poll: We want non-deleted ostream inserters for physical unit types in D1935R1?
Attendance: 8

That does not have consensus.

Poll: We want std::format support for physical unit types in D1935R1?
Attendance: 7

That has consensus.

A: Should provide both std::format and ostream inserters or neither.

Poll: Do we want to support localization in D1935R1?
Attendance: 7

That has consensus.

SA: Round tripping is important, localization is better handled outside of the standard.

Poll: For D1935R1, Localization should be provided via std::locale?
Attendance: 7

That does not have consensus.

SA: We need a better solution than std::locale.
F: std::locale is all we got, man!

Poll: For D1935R1, it is ok to provide ostream inserters that are not locale sensitive?
Attendance: 7

That has consensus.
SA: If we have localization support in std::format, then we should have it in ostream support as well.

Removing the SG16 label as recent revisions appear to be inline with previous SG16 guidance. I trust that the LEWG chair will involve SG16 if relevant concerns arise. In particular, SG16 should be consulted if new revisions introduce localization support or the ability to stream/format unit suffixes that contain characters from outside the basic source character set.

Closing due to more than 1 year of inactivity. Please re-open if further work is expected.