Date: Wed, 13 Mar 2024 10:13:52 -0400
I plan to attend today for the discussion on deprecating signed characters
in iostreams, but I have a meeting at 3:00PM that might run late.
It would be helpful if that deprecated discussion ran second.
AlisdairM
> On 12 Mar 2024, at 17:52, Tom Honermann via SG16 <sg16_at_[hidden]> wrote:
>
> This is your friendly reminder that this meeting is taking place tomorrow.
> Please don't forget about the DST change!
> Tom.
> On 3/9/24 11:35 PM, Tom Honermann via SG16 wrote:
>> SG16 will hold a meeting on Wednesday, March 13th, at 19:30 UTC (timezone conversion).
>> For those in North America, please note that daylight savings time will have begun, so this telecon will begin one hour later relative to the last telecon.
>> The agenda follows.
>> • P3154R0: Deprecating signed character types in iostreams.
>> • P1729R4: Text Parsing.
>> P3154R0 seeks to deprecate the basic_istream<char, ...> extraction and basic_ostream<char, ...> insertion operators that treat signed char and unsigned char as character types. This is motivated by common use of these types as integer types (int8_t and uint8_t) and the desire to remove surprising behavior that occurs when these types are used with iostreams. Deprecation and eventual removal could clear the way for eventually replacing the current operators with ones that treat these types as integer types for all charT stream types. It is perhaps worth noting that this is not the only place in the C++ standard that treats these types as character types. Following adoption of P2513 (char8_t Compatibility and Portability Fixes) for C++23, an array of unsigned char may be initialized with a UTF-8 string literal. This leniency was added for compatibility with C where char8_t is a type alias of unsigned char.
>> SG16 has reviewed prior versions of P1729R4 on several occasions:
>> • 2023-11-11 SG16 review of P1729R3.
>> • 2023-09-27 SG16 review of P1729R2.
>> • 2019-06-22 SG16 review of P1729R0 in Cologne.
>> This latest revision incorporates changes requested by SG9 and elevates ill-formed encoding input from garbage to errors per previous SG16 discussion (see section 4.11, Encoding). The last SG16 review included discussion of text vs binary input. Elias can clarify, but I believe the current proposal focuses on text support and would require custom formatters to be written to handle binary input (which is fine). I think other previously raised SG16 concerns have been addressed, so this review can focus on any new concerns or we can poll to forward the paper.
>> Tom.
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
in iostreams, but I have a meeting at 3:00PM that might run late.
It would be helpful if that deprecated discussion ran second.
AlisdairM
> On 12 Mar 2024, at 17:52, Tom Honermann via SG16 <sg16_at_[hidden]> wrote:
>
> This is your friendly reminder that this meeting is taking place tomorrow.
> Please don't forget about the DST change!
> Tom.
> On 3/9/24 11:35 PM, Tom Honermann via SG16 wrote:
>> SG16 will hold a meeting on Wednesday, March 13th, at 19:30 UTC (timezone conversion).
>> For those in North America, please note that daylight savings time will have begun, so this telecon will begin one hour later relative to the last telecon.
>> The agenda follows.
>> • P3154R0: Deprecating signed character types in iostreams.
>> • P1729R4: Text Parsing.
>> P3154R0 seeks to deprecate the basic_istream<char, ...> extraction and basic_ostream<char, ...> insertion operators that treat signed char and unsigned char as character types. This is motivated by common use of these types as integer types (int8_t and uint8_t) and the desire to remove surprising behavior that occurs when these types are used with iostreams. Deprecation and eventual removal could clear the way for eventually replacing the current operators with ones that treat these types as integer types for all charT stream types. It is perhaps worth noting that this is not the only place in the C++ standard that treats these types as character types. Following adoption of P2513 (char8_t Compatibility and Portability Fixes) for C++23, an array of unsigned char may be initialized with a UTF-8 string literal. This leniency was added for compatibility with C where char8_t is a type alias of unsigned char.
>> SG16 has reviewed prior versions of P1729R4 on several occasions:
>> • 2023-11-11 SG16 review of P1729R3.
>> • 2023-09-27 SG16 review of P1729R2.
>> • 2019-06-22 SG16 review of P1729R0 in Cologne.
>> This latest revision incorporates changes requested by SG9 and elevates ill-formed encoding input from garbage to errors per previous SG16 discussion (see section 4.11, Encoding). The last SG16 review included discussion of text vs binary input. Elias can clarify, but I believe the current proposal focuses on text support and would require custom formatters to be written to handle binary input (which is fine). I think other previously raised SG16 concerns have been addressed, so this review can focus on any new concerns or we can poll to forward the paper.
>> Tom.
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
Received on 2024-03-13 14:14:06