Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
AlexGuteniev opened this issue Jul 2, 2020 · 4 comments
Labels
enhancement Something can be improved

Comments

@AlexGuteniev
Copy link
Contributor

See #795 (comment)

@AlexGuteniev AlexGuteniev added the question Further information is requested label Jul 2, 2020
@StephanTLavavej StephanTLavavej added decision needed We need to choose something before working on this enhancement Something can be improved and removed question Further information is requested labels Jul 2, 2020
@StephanTLavavej
Copy link
Member

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
Copy link
Member

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

@BillyONeal
Copy link
Member

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 StephanTLavavej removed the decision needed We need to choose something before working on this label Jul 13, 2022
@StephanTLavavej
Copy link
Member

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.

@StephanTLavavej StephanTLavavej closed this as not planned Won't fix, can't repro, duplicate, stale Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Something can be improved
Projects
None yet
Development

No branches or pull requests

3 participants