Prague 2020-02 LEWGI Minutes

P1944R0 constexpr <cstring> and <cwchar>: Direction Review

Chair: Fabio Fracassi

Champion: Antony Polukhin

Minute Taker: Ben Craig

Start Review: 2020-02-13 09:16

Changing the definition of <cstuff> from namespace std { using ::stuff; } to defining our own version in <cstuff>

Start Polling: 09:28

POLL: We think this is important enough that we want to spend more time on this problem.

Attendance: 19

# of Authors: 1

Author Position: SF

A: I don't think we should be using C interfaces like this.

That has strong consensus.

POLL: We want to add std::strtok(char*, char*, char**).

Attendance: 19

# of Authors: 1

Author Position: N

That has no consensus.

Find the prior discussions on adding constexpr to <cstuff> headers, consult implementors, and add what you learn to the next revision.

Consult SG16 on this paper regarding locales.

End: 09:36

CONSENSUS: Bring a revision of P1944R0 (constexpr <cstring> and <cwchar>), with the guidance below, to LEWGI for further design review.

• Remove std::strtok(char*, char*, char**).
• Find the prior discussions on adding constexpr to <cstuff> headers, consult implementors, and add what you learn to the next revision.
• Consult SG16 on this paper regarding locales.

P1944R1 Add Constexpr Modifiers to Functions in cstring and cwchar Headers (Daniil Goncharov, Antony Polukhin)

Mailing list review 5-19 October 2020

• We want to see at least one implementation in a standard library

• The paper should mention of <string.h> and <wchar.h>

• Do we need all of these functions? Is our time not better spent on improving higher level facilities? Some of these higher level facilities may need these C functions

• Author note that some of these functions are constant evaluated in clang https://releases.llvm.org/5.0.1/tools/clang/docs/LanguageExtensions.html#string-builtins - ditto for GCC but there are corner cases where it doesn't work

• This proposal for some implementations requires changing either the lib c or the compiler

• There is a requirement that &std::strlen == &::strlen

• Why do we have this requirement - can wee change it ? (Note from myself: SD-8 forbids observing the address of standard names) - some functions like memchr already deal with this problem

• This proposal is more work than assumed by the paper. If we do it we should know it will require some implementer work

Guidance: Implement the paper in a standard library / compiler, taking into account that the implementation may not be able to change the C headers. Talks to implementers on the best way to proceed

Re-adding the mailing-list review tag so that this will automatically be triaged when a new revision comes: mailing list review managers, here are some saved queries that filter out things that are needs-revision, etc.

Thy will be done.

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