vector<👻>: move algorithms to import library

[AlexGuteniev]

There are some algorithms specialized for vector<👻>.

They are templated on iterator type. Since there are limited number of iterator types, they can be moved to import lib, which could export all possible instantiation.

This will save throughput. Also for the cases where lambda is used there, it may reduce code bloat.

Should this be done?

[AlexGuteniev]

Though due to constexpr some implementation has to stay in header, then probably only runtime version should move

[StephanTLavavej]

In general, I think that the headaches of separately compiled code outweigh possible throughput improvements. Only in extreme cases like charconv's enormous static tables does separate compilation seem valuable. (Personal opinion developed after a decade+ of struggling with separately compiled code.)

Casey Carter (@CaseyCarter) notes that he's concerned about blocking things with ABI issues.

[frederick-vs-ja]

I think we can turn these algorithms (and the planned _Copy_vbool) into non-template functions, which can also reduce code bloat due to lambda.

E.g., perhaps we should change _Fill_vbool to this:

_CONSTEXPR20 void _Fill_vbase_off(
    _Vbase* _First_vb, const size_t _First_off, _Vbase* const _Last_vb, const size_t _Last_off, const bool _Val) noexcept {
    // ...
}

But I don't think it's worthy to move "only runtime version" to the import library, since the runtime and compile time versions largely shared codes.

[StephanTLavavej]

I think it's also worth noting that modules change throughput considerations - in the modules world which is where the ecosystem should be moving towards, the cost of having code in "headers" is much less.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting and concluded that for the reasons discussed above, there aren't major throughput gains to be had in separately compiling vector<bool> machinery, and significant complexity cost to doing so. Thanks again for the suggestion!