`<flat_set>`: optimize `unique` algorithm call

[AlexGuteniev]

STL/stl/inc/flat_set

Lines 708 to 716 in 6314950

	void _Erase_dupes_if_not_multi() {
	if constexpr (_IsUnique) {
	const auto _Equivalent = [this](const _Kty& _Lhs, const _Kty& _Rhs) {
	return !_Compare(_Lhs, _Rhs) && !_Compare(_Rhs, _Lhs);
	};
	const auto _End = _Mycont.end();
	_Mycont.erase(_STD unique(_Mycont.begin(), _End, _Equivalent), _End);
	}
	}

This could have been vectorized unique, but the predicate is on the way.

For less<>, less<T>, ranges::less predicate and for usual types, the equivalence can be replaced with binary equality, and the predicate can be omitted.

In the case of predicate-less unique call for normal underlying container (like, not deque) the unique will be vectorized using already existing code path.

---

For flat_map this could work in principle too, but would effectively require implementing vector algorithms in headers, and would be way more tedious, so that's probably not what we would do, at least in a near future.

[StephanTLavavej]

For less<>, less<T>, ranges::less predicate and for usual types, the equivalence can be replaced with binary equality, and the predicate can be omitted.

The greater family too, if someone wants to have a flat_meow with reversed order.

"Usual types" is the key point here - I think we'd want to optimize for integers, basic_string, and basic_string_view, since those will be the most common key types. Obviously the strings can't be vectorized, but avoiding the less-than comparisons will be important, and string equality is even better because it will short-circuit for different lengths. (I forget whether, with custom traits, we can collapse equivalence into equality. We could special-case for default traits which are used 99.9% of the time and lose nothing.)

[AlexGuteniev]

Strings are other thing, have not thought of that. Was thinking of non-bool integers and pointers.

For string it makes sense to do it for flat_map either.