`<flat_map>`: Shouldn't the non-default `_Pairing_iterator_provider::_Iterator` ctor be private?

[vmichal]

Followup on #6034 :
I believe we can (and should) make _Pairing_iterator_provider::_Iterator constructor private in the same way as that of value_compare.

The following code currently compiles, and I'm not convinced this is intended (note the + 1 added to values iterator).

using C = flat_map<int, char>;
typename C::key_container_type keys{42, 137, 137, 3337, 0};
typename C::mapped_container_type values{'a', 'g', 'f', 'f', 'r'};
typename C::iterator iter{keys.begin(), values.begin() + 1};

In #6035 I have added assertions that would prevent operations with iter in the example above. But making the constructor private seems even more robust as it prevents creating such iterators completely (unless we had a bug in flat_map).

[StephanTLavavej]

Yes, I strongly agree - if we can lock down such constructions, we should. Users have no right to directly create our iterators.

[vmichal]

Yes, I strongly agree - if we can lock down such constructions, we should. Users have no right to create our iterators directly.

Alright, I will do that and add to #6035.
If we make the ctor private, we can't simply break invariants and thus create death tests for those _Key_it - _Right._Key_it == _Mapped_it - _Right._Mapped_it assertions added in #6035. Do you have a preferred method for testing those (if at all)? There are multiple hacks: #define private public (joke) or befriending some testing-specific class, but I don't see a clean way.