On Fri, 22 Jul 2022, 19:37 Thiago Macieira via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
On Friday, 22 July 2022 11:11:21 PDT Hyman Rosen wrote:
> On Fri, Jul 22, 2022 at 11:24 AM Thiago Macieira via Std-Proposals <
> std-proposals@lists.isocpp.org> wrote:
> > Hence the rule: NEVER use a std::pair. There are no exceptions, zero,
> > nada,
> > nil.
>
> If we cannot trust the language standardization process to produce a usable
> library type that just represents a pair of things, why would we trust it
> to produce usable library types for concurrent programming, or for anything
> else, for that matter?  Isn't this a sign that something is dreadfully
> wrong?

No. The problem is not with std::pair. There's nothing wrong with the class as
standardised (which was C++98, so it's dated) or implemented.

No, the problem is in your attempting to use it. In any case where you know
you need exactly two things, they have names or meanings. "first" and "second"
are not good member names.

Therefore, the problem with std::pair is that there are ZERO valid use-cases
calling for its use where there isn't a better solution available. 


Pair is useful in the abstract case (abstract nonsense, to abuse a term of art) where you don't actually care what the elements are. Foundational computer science certainly has enough binary relations that abstract the nature of their referents. 

In the concrete case, I agree that you should give better names to the elements.