Considering it would break compatibility with every non-EN_US batch file on the planet, I’m betting that the probability is still going to be close to 0 even 10 – 20 years from now. It certainly won’t be more than 50%.

Keep in mind even on the latest Win10 bits that’s an experimental switch hidden deep within pages of options menus; I don’t know of any plans to change the defaults to UTF-8 for any of the default locales. The appcompat fallout would be quite high given the previous assumption that multibyte code pages could use at most 2 encoding units. (I don’t work in Windows and don’t *know* about plans or lack thereof to make such a change but it would surprise me)

Case in point: if the program in question is compiled with a VS version older than 2017 Update 9 and the user tries to turn that option on, then iostreams + locales assert in debug mode and corrupt memory in release mode.

Billy3

________________________________
From: Tom Honermann <tom_at_[hidden]>
Sent: Monday, September 9, 2019 12:46:13 PM
To: Billy O'Neal (VC LIBS) <bion_at_[hidden]>; Corentin <corentin.jabot_at_[hidden]>
Cc: Zach Laine <whatwasthataddress_at_[hidden]>; Library Working Group <lib_at_[hidden]>; Victor Zverovich <victor.zverovich_at_[hidden]>; unicode_at_[hidden] <unicode_at_[hidden]>
Subject: Re: [isocpp-lib] New issue: Are std::format field widths code units, code points, or something else?

On 9/9/19 3:33 PM, Billy O'Neal (VC LIBS) wrote:
> everything within the programs assumes ACP, if you are trying to say output to the console, and the ACP is utf8, the console has to expect utf8

The probability of ACP being UTF-8 is approximately zero.

Today, yes. What does your crystal ball say about 10 or 20 years from now?

Tom.