Should STL try to avoid introducing standard identifiers without corresponding header included?

[AlexGuteniev]

See #795 (comment)

[StephanTLavavej]

The implementation acts contrary to such a goal whenever it defines machinery in centralized headers for maintainer convenience:

STL/stl/inc/xtr1common

Lines 41 to 46 in 5e3423a

	using true_type = bool_constant<true>;
	using false_type = bool_constant<false>;
	// STRUCT TEMPLATE enable_if
	template <bool _Test, class _Ty = void>
	struct enable_if {}; // no member "type" when !_Test

And when headers include other headers:

STL/stl/inc/tuple

Lines 11 to 13 in 5e3423a

	#include <new>
	#include <type_traits>
	#include <xutility>

The latter can have significant throughput consequences in addition to identifier cleanliness, and we've reduced some of that over time.

I tend to feel that identifier cleanliness can't really be achieved without modules so it's futile to try, although it is worth investigating and mitigating significant throughput impacts (e.g. avoid including <animals> when we only need std::tiny_kitten).

We should definitely make a decision though. Thanks for filing this.

[BillyONeal]

I don't think we could reasonably achieve this before modules.

[BillyONeal]

I've attempted to do something like this before and we were forced to back it out because way too many things broke; for example this is why <string> drags in <cctype> even though nothing in <string> uses that.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting and concluded that this is indeed not feasible - we need far too many bits of the STL to implement other components, and providing _Ugly machinery that mirrors Standard machinery would result in duplication, debug codegen bloat, and throughput reductions.

Standard Library Modules will be disciplined about exporting only Standard machinery (and only in namespace std for the import std; module), although the std and std.compat modules export everything from array to zip.