Date: Tue, 7 Dec 2021 23:04:45 +0000
The general version is much more complicated and more difficult to design than what format needs to be able to do. Format only needs to go forward, and generally doesn't care about bulk conversion, but sometimes does care about consistent handling of bogus data. This generally leads one down the path of a pretty simple "by the book" transcoding routine that's much slower than what's possible for some other sets of requirements.
I don’t really want to have to design a text transcoding API to finish implementing format :D
-----Original Message-----
From: SG16 <sg16-bounces_at_lists.isocpp.org> On Behalf Of Jens Maurer via SG16
Sent: Sunday, December 5, 2021 11:27 AM
To: Tom Honermann <tom_at_honermann.net>; Corentin Jabot <corentinjabot_at_gmail.com>
Cc: Jens Maurer <Jens.Maurer_at_[hidden]>; SG16 <sg16_at_lists.isocpp.org>; Barry Revzin <barry.revzin_at_gmail.com>
Subject: Re: [SG16] Agenda for the 2021-12-01 SG16 telecon
On 05/12/2021 01.04, Tom Honermann wrote:
> On 12/4/21 6:05 AM, Jens Maurer wrote:
>> If we impose a requirement for a code unit -> code point decoder for
>> the literal encoding at compile-time, we should make such a facility
>> generally available instead of hiding it in the guts of the std::format parser.
> I think JeanHeyd's work on P1629 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2Fp1629&data=04%7C01%7CCharles.Barto%40microsoft.com%7C99243a98839e436bb7b008d9b82538eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637743292286958540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=idthIRVjvVmYWyjGZZ6l%2FzEjOULRXWqihZSuTKiVKcw%3D&reserved=0> will fill this niche. It would be nice if the features he proposes in N2730 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn2730.htm&data=04%7C01%7CCharles.Barto%40microsoft.com%7C99243a98839e436bb7b008d9b82538eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637743292286958540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SBTy9zMu0BgQ9jVrXgoErVwOWw65WMfgGiuXjCerKmw%3D&reserved=0> were usable at compile-time as well, but that will likely have to await some kind of constexpr support in C.
Why? We've made functions constexpr that are inherited from C before.
>>> It makes me wonder if some of these features should be restricted to
>>> u8 formatting strings 😅
>> We even have a "u8" string literal prefix to indicate UTF-8 string literals.
>> What a foresight.
>
> Perhaps some day we'll even be able to pass such strings to std::format()!
We can't be so modern.
Jens
--
SG16 mailing list
SG16_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg16&data=04%7C01%7CCharles.Barto%40microsoft.com%7C99243a98839e436bb7b008d9b82538eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637743292286958540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gvvQ%2F7Rl4K7pSvsi8PoCGRc5BLjWB98Wg%2B27Drp%2Fm5Y%3D&reserved=0
I don’t really want to have to design a text transcoding API to finish implementing format :D
-----Original Message-----
From: SG16 <sg16-bounces_at_lists.isocpp.org> On Behalf Of Jens Maurer via SG16
Sent: Sunday, December 5, 2021 11:27 AM
To: Tom Honermann <tom_at_honermann.net>; Corentin Jabot <corentinjabot_at_gmail.com>
Cc: Jens Maurer <Jens.Maurer_at_[hidden]>; SG16 <sg16_at_lists.isocpp.org>; Barry Revzin <barry.revzin_at_gmail.com>
Subject: Re: [SG16] Agenda for the 2021-12-01 SG16 telecon
On 05/12/2021 01.04, Tom Honermann wrote:
> On 12/4/21 6:05 AM, Jens Maurer wrote:
>> If we impose a requirement for a code unit -> code point decoder for
>> the literal encoding at compile-time, we should make such a facility
>> generally available instead of hiding it in the guts of the std::format parser.
> I think JeanHeyd's work on P1629 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwg21.link%2Fp1629&data=04%7C01%7CCharles.Barto%40microsoft.com%7C99243a98839e436bb7b008d9b82538eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637743292286958540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=idthIRVjvVmYWyjGZZ6l%2FzEjOULRXWqihZSuTKiVKcw%3D&reserved=0> will fill this niche. It would be nice if the features he proposes in N2730 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg14%2Fwww%2Fdocs%2Fn2730.htm&data=04%7C01%7CCharles.Barto%40microsoft.com%7C99243a98839e436bb7b008d9b82538eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637743292286958540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SBTy9zMu0BgQ9jVrXgoErVwOWw65WMfgGiuXjCerKmw%3D&reserved=0> were usable at compile-time as well, but that will likely have to await some kind of constexpr support in C.
Why? We've made functions constexpr that are inherited from C before.
>>> It makes me wonder if some of these features should be restricted to
>>> u8 formatting strings 😅
>> We even have a "u8" string literal prefix to indicate UTF-8 string literals.
>> What a foresight.
>
> Perhaps some day we'll even be able to pass such strings to std::format()!
We can't be so modern.
Jens
--
SG16 mailing list
SG16_at_[hidden]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg16&data=04%7C01%7CCharles.Barto%40microsoft.com%7C99243a98839e436bb7b008d9b82538eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637743292286958540%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=gvvQ%2F7Rl4K7pSvsi8PoCGRc5BLjWB98Wg%2B27Drp%2Fm5Y%3D&reserved=0
Received on 2021-12-07 17:04:49