P3154 R1 Deprecating signed character types in iostreams

[wg21bot]

P3154R0 Deprecating signed character types in iostreams (Elias Kosunen)

[inbal2l]

@tahonermann - can you please look at this first, especially on the breakage aspect? (the paper is a bit light in exploring this).

[tahonermann]

@tahonermann - can you please look at this first, especially on the breakage aspect? (the paper is a bit light in exploring this).

Yes, will do.

[fdwr]

👍 Goodness.

The semantic conflation between characters and integers here (uint8_t being defined in terms of unsigned char, whereas uint16_t is not defined in terms of say unsigned char16_t) is the root issue. Attempting to compile signed char32 or unsigned char16_t rightly gives you a build warning, and ideally so would signed char and unsigned char (if they weren't already too entrenched in history).

[tahonermann]

@fdwr, this repository is only used for administrative management, not for general discussion. Please consider using the std-discussion and/or std-proposals mailing lists for general discussion.

[tahonermann]

SG16 reviewed P3154R0 during it's 2024-03-13 meeting. The following polls were taken.

Poll 1: Recommend reserving signed char and unsigned char for use as integer types, not character types.

• Attendees: 11 (1 abstention)

  SF	F	N	A	SA
  7	2	0	1	0

• Consensus in favor.

Poll 2: Forward P3154R0 with the suggested modifications to the motivation section to LEWG for C++26.

• Attendees: 11 (3 abstentions)

  SF	F	N	A	SA
  4	2	1	1	0

• Consensus in favor.

With regard to the first poll, SG16 encourages LEWG to treat these types as integer types within the standard library, at least with regard to reading and writing text. However, LEWG might want to keep in mind the implications of WG14 using unsigned char as the target type for its char8_t type alias and the corresponding compatibility accommodations that have already been adopted via P2513R4 (char8_t Compatibility and Portability Fix). The against vote on this poll was due to a desire to get implementation experience with the proposed deprecations before settling on a recommendation.

With regard to the second poll, the against vote and the abstentions were due to uneasiness with SG16 stating a position on deprecation since the desired remedy for the situation is more of a LEWG concern. The SG16 chair interprets this as a failure on his part to adequately describe his intent with polling to forward the paper (that intent is to indicate that SG16 believes that concerns that fall within SG16's purview are either adequately addressed or appropriately discussed in the paper). The SG16 chair will strive to make such intent more clear in future polls.

Removing the SG16 label, this paper rests in LEWG's good hands.

[wg21bot]

P3154R1 Deprecating signed character types in iostreams (Elias Kosunen)