`<xlocale>`: `locale::empty` is non-Standard

[cpplearner]

The std::locale class provides a member empty, which is not part of the standard.

STL/stl/inc/xlocale

Line 403 in 89ca073

static _MRTIMP2_PURE locale __CLRCALL_PURE_OR_CDECL empty(); // empty (transparent) locale

This member is documented on https://learn.microsoft.com/en-us/cpp/standard-library/locale-class?view=msvc-170:

In this implementation, you can also call the static member function:

static locale empty();

to construct a locale object that has no facets. It's also a transparent locale. If the template functions has_facet and use_facet can't find the requested facet in a transparent locale, they consult first the global locale and then, if that is transparent, the classic locale. So, you can write:

cout.imbue(locale::empty());

Subsequent insertions to cout are mediated by the current state of the global locale.

It seems that this member is used by a few projects to read UTF-8 files, possibly (mis)guided by https://stackoverflow.com/a/10607146/4672588.

Is there any interest to deprecate and eventually remove this non-Standard extension?

[frederick-vs-ja]

I'd like to directly remove the extension, but at this moment it should be preserved in #ifdef _CRTBLD.

In #3088 the locale::c_str extension was effectively removed. It seems also doable to some _Uglify the function name.

CC Tyler Whitney (@TylerMSFT).

[CaseyCarter]

If there's usage in the wild, we'll want to deprecate or remove-with-escape-hatch rather than simply hide it in #ifdef _CRTBLD.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting. Unconditionally deprecating now, and later guarding the declaration with #ifdef _CRTBLD to conceal it from users, seems like a reasonable strategy. If we see lots of RWC impact from the deprecation, then we can revise this plan, but I suspect that real-world usage will be very unlikely, even though this has been provided for decades.

We've also contacted the docs team to stop documenting locale::empty().

[StephanTLavavej]

Fixed by #5834.