Date: Fri, 27 Nov 2020 15:00:27 +0000
On 27/11/2020 14:38, Tom Honermann via SG16 wrote:
> A few other items that I would like to see the paper discuss:
>
> Writing bytes.
Personally speaking, I'd prefer if the default for print() were left
implementation defined. Then when we get the inevitable consteval
print(), the implementation can define defaults differently depending on
evaluation context.
> For example, filenames. I don't think there is a right
> answer for filenames; some valid filenames cannot be displayed
> accurately in any well-formed encoding. Perhaps a 'formatter'
> specialization should be provided for std::filesystem::path? Proposing
> something like that is likely subject matter for a different paper, but
> I think it would be helpful for this paper to discuss it.
It may be useful to know that LEWG must bite this bullet when deciding
how to render unencoded byte path views to ostream. I'm currently
proposing implementation defined, but the textual representation must
NOT be any valid path, EXCEPT when on this implementation binary
filesystem paths are supported. So, for example, on Windows:
"C:\{de81bd61-4434-4920-99bd-183230770d60}"
... is a perfectly valid path on NTFS, and thus unencoded byte path
views, if exactly 16 bytes long, ought to be textualised as the above.
If however the unencoded path view were not 16 bytes long, then:
path://7B%89%1D%B1%DEo%80%01%F4%23%0F%D9Is~%29
... might be as good as any as a path representation which is not valid
on the local implementation.
> Transcoding errors. The Windows native console interface requires
> UTF-16 (assuming use of WriteConsoleW() as I believe is used by FMT).
> That means transcoding the std::print() input from UTF-8 to UTF-16.
> What happens if the UTF-8 input is ill-formed?
If you leave what print() prints to implementation defined, you can wave
away all such concerns. I would also add that the configuration of the
console you are outputting to (assuming there is one) can vary. For
example, Win32 apps might output to the Win32 console, but they might
instead output to a PowerShell console, or even a proper Unix style TTY.
Depends on runtime configuration. Separately, if you are printing from
consteval, then it is whatever the compiler's output is, and it too may
be in one of many runtime configurations.
Niall
> A few other items that I would like to see the paper discuss:
>
> Writing bytes.
Personally speaking, I'd prefer if the default for print() were left
implementation defined. Then when we get the inevitable consteval
print(), the implementation can define defaults differently depending on
evaluation context.
> For example, filenames. I don't think there is a right
> answer for filenames; some valid filenames cannot be displayed
> accurately in any well-formed encoding. Perhaps a 'formatter'
> specialization should be provided for std::filesystem::path? Proposing
> something like that is likely subject matter for a different paper, but
> I think it would be helpful for this paper to discuss it.
It may be useful to know that LEWG must bite this bullet when deciding
how to render unencoded byte path views to ostream. I'm currently
proposing implementation defined, but the textual representation must
NOT be any valid path, EXCEPT when on this implementation binary
filesystem paths are supported. So, for example, on Windows:
"C:\{de81bd61-4434-4920-99bd-183230770d60}"
... is a perfectly valid path on NTFS, and thus unencoded byte path
views, if exactly 16 bytes long, ought to be textualised as the above.
If however the unencoded path view were not 16 bytes long, then:
path://7B%89%1D%B1%DEo%80%01%F4%23%0F%D9Is~%29
... might be as good as any as a path representation which is not valid
on the local implementation.
> Transcoding errors. The Windows native console interface requires
> UTF-16 (assuming use of WriteConsoleW() as I believe is used by FMT).
> That means transcoding the std::print() input from UTF-8 to UTF-16.
> What happens if the UTF-8 input is ill-formed?
If you leave what print() prints to implementation defined, you can wave
away all such concerns. I would also add that the configuration of the
console you are outputting to (assuming there is one) can vary. For
example, Win32 apps might output to the Win32 console, but they might
instead output to a PowerShell console, or even a proper Unix style TTY.
Depends on runtime configuration. Separately, if you are printing from
consteval, then it is whatever the compiler's output is, and it too may
be in one of many runtime configurations.
Niall
Received on 2020-11-27 09:00:31