STL: Consider renaming <xmeow> internal headers

[StephanTLavavej]

Many of our internal headers follow an <xmeow> naming convention (which is convenient as no Standard headers begin with x). Recently, we've been giving them extensions, like <xnode_handle.h> (mostly because the VS IDE needs to be updated when extensionless headers are added, so that they can be recognized as C++). We also have 3 internal headers of the form <ymeow.h>: <ymath.h>, <yvals.h>, and <yvals_core.h>. We have 1 internal header named <__msvc_all_public_headers.hpp> (which is for test purposes, not product code).

It's relatively uncommon, but we've noticed users occasionally including these internal headers (which are undocumented and unsupported; we frequently change their contents, and occasionally rename/delete the headers). We should consider changing this convention, but we need to decide on a consistent naming pattern (and probably choose better names for many of the headers; e.g. <xtr1common> is confusing).

Note: This will break user code, including the Windows codebase.

Ideas:

• <__msvc_internal_meow.hpp>
• <__msvc_stl_internal_meow.hpp>
• <__stl_internal_meow.hpp>

[BillyONeal]

I tried so hard :)

[AdamBucior]

Maybe we could replace <yvals_core.h> with <version>. Everything <version> does is including <yvals_core.h>. <version> seems like a good place for everything <yvals_core.h> contains.

[StephanTLavavej]

We tried that, but surprisingly it's a source breaking change. The problem is that there are projects that have files named VERSION, and also compile with /I pointing to that directory. This breaks any code that includes <version>, because the /I directory is searched before the STL. Therefore, <version> must not be dragged in by any STL header.

(We're willing to perform source breaking changes in pursuit of conformance, throughput, or other worthy goals, but simplifying our internal header structure isn't worth it.)

[CaseyCarter]

We tried that, but surprisingly it's a source breaking change

One of my favorite commit logs:

[sylveon]

Might be worth investigating in vNext, since that's already ABI breaking, and <version> is a C++20 header so people moving to vNext and/or C++20 shouldn't expect <version> to work when pointing at their own stuff (just like nobody expects doing the same to <algorithm> or <type_traits> to work).

[StephanTLavavej]

While vNext is inherently ABI breaking, and will almost certainly contain a fair number of source breaks, we still have a finite "source break budget" that we need to spend carefully, otherwise migrating to vNext will be unnecessarily onerous.

Additionally, while <version> was added by C++20, we provide it unconditionally. Using it unconditionally (instead of <yvals_core.h>) would break C++14/17 users, while using it conditionally would achieve nothing.

[MikeGitb]

Just throwing this in here:

#include "./__msvc_stl_internal/meow.hpp"

I.e. put them in a separate folder

[AdamBucior]

Just throwing this in here:

#include <__msvc_stl_internal/meow.hpp>

I.e. put them in a separate folder

I also thought about it.

[MikeGitb]

Btw. msvc's stl needs a (nick) name.

[BillyONeal]

Btw. msvc's stl needs a (nick) name.

STLSTL

[BillyONeal]

This is tracked by Microsoft-internal task VSO-961234 "Internal and public headers should be easier to tell apart"