That would actually make things worse, as no major OS vendor is Unicode compliant.

________________________________
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 Sat, 7 Sept 2024 at 22:41, Andrey Semashev via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
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]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals