P1642R11 Freestanding Library: Easy `[utilities]`, `[ranges]`, And `[iterators]`

[StephanTLavavej]

P1642R11 Freestanding Library: Easy [utilities], [ranges], And [iterators]
LWG-3814 Add freestanding items requested by NB comments

For our hosted implementation, there is likely nothing to do here.

This paper intentionally doesn't change any feature-test macros.

[frederick-vs-ja]

Components provided in MSVC STL's core headers are almost the subset of freestanding components (plus C23 freestanding components and P2338). The major exceptions are that many non-freestanding C library components, e.g. <clocale>, are STL-core components.

Some freestanding components are not STL-core:

• Heap-related components, i.e. operator new and operator delete in <new> and helper types.
  • Placement operator new and operator delete seem to be core components and used by default_initializable, etc..
• Exception-related components in <exception>, etc..
• RTTI-related components in <typeinfo>.
• Range-related components in <iterator>, <ranges>, and <memory>.
  • For "concrete" iterators and ranges (including input of algorithms), STL verifies the range during debug whenever possible, and the utilities used for verification are non-core.
  • For "abstract" range components (concepts, iterator_traits, etc.), it seems that they are suitable to be core, and I made some of them core in <tuple>: Becomes a core header #2730.
• Other missing pieces, e.g. mem_fn.

In conclusion, I think it would be an improvement to make abstract range utilities and "other missing pieces" core components. The downside is that

• either we will have to expose more non-standard core headers, or
• we will have to move more components to existing core headers, which will damage throughput when including these headers only.

[StephanTLavavej]

I tend to think that our notion of "core" is too different from "freestanding" to tie these things together. (Also what we consider "core" isn't exactly crisply defined.) Marking as decision needed.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting and decided to resolve this as "nothing to do for our hosted implementation". As I mentioned, we'll continue to explore exactly what being a "core" header involves, but this should not be connected to the Standard's definition of freestanding machinery.

[frederick-vs-ja]

May be related to #1289.