On Sep 9, 2024, at 12:34 AM, Tiago Freire <tmiguelf_at_[hidden]> wrote:
It means, file system is not Unicode, terminal inputs are not Unicode, system understanding of text (wherever that shows up) is not Unicode, even in modes labeled "utf-8" or suggesting that they are "Unicode".
None of that is relevant for this proposal. The proposal wasn’t to support everything in the Unicode Standard; it was to support UTF-8.
Any attempt to add such a feature would only achieve making an application that uses it not compatible with any OS.
That is just incorrect. The native OS program arguments will be affiliated with some implementation-defined encoding. Adding a transcoding layer on top of them does not introduce incompatibility. Programmers still have to adhere to encoding expectations of any functions called.
Tom.
From: Tom Honermann <tom_at_[hidden]>
Sent: Sunday, September 8, 2024 11:22:45 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] Floating an idea: int main(std::span<std::string_view> args)
On Sep 8, 2024, at 3:42 PM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
That would actually make things worse, as no major OS vendor is Unicode compliant.
I fail to see what an OS being Unicode compliant (whatever that means; there is no Unicode specification for operating systems) has to do with this.
As long as the implementation knows what encoding to convert from, a signature that provides a UTF-8 interface is possible. However, since the external input might not be properly encoded, such a proposal should specify how transcoding errors are handled.
Implicitly linking to an alternate file I/O library doesn’t seem realistic to me. Such a change in encoding expectations should be expressed such that every translation unit is aware. Otherwise, a programmer has no way of knowing what encoding to use with
such interfaces.
Tom.
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of zxuiji via Std-Proposals <std-proposals_at_[hidden]>
Sent: Sunday, September 8, 2024 9:14:51 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: zxuiji <gb2985_at_[hidden]>
Subject: Re: [std-proposals] Floating an idea: int main(std::span<std::string_view> args)
I would rather propose int umain( int argc, char8_t **argv ) { ... }
The presence of which would indicate to the compiler to slap some extra code into the startup function to active UTF8 mode in the terminal and link variants of open() etc that expect UTF8 paths. This would vastly simplify development if the interactions
between the system and the program have translations handled in the background instead of forcing it onto the developer.
On 9/8/24 00:21, Thiago Macieira via Std-Proposals wrote:
> On Saturday 7 September 2024 22:11:32 CEST Jeremy Rifkin via Std-Proposals
> wrote:
>> If I understand correctly P0781 was written before std::span was
>> proposed and suggested some magic std::argument_list. Now that there's a
>> standard replacement for pointer+length, is it worth reconsidering?
>
> std::span requires that there be a contiguous range of the value_types in
> memory somewhere. That's the problem here: std::string_view aren't there. We
> could use a std::span<std::cstring_view> but no one wants to standardise
> cstring_view.
cstring_view also aren't there, unless you're willing to mandate its
binary representation as a single pointer and legalize type punning.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
