On Fri, 22 Jul 2022, 19:37 Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> 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_at_[hidden]> 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.



>