stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <>
Subject RE: Tuple status
Date Mon, 07 Jul 2008 16:21:48 GMT

> -----Original Message-----
> From: Martin Sebor [] On Behalf Of Martin Sebor
> Sent: Thursday, July 03, 2008 9:16 AM
> To:
> Subject: Re: Tuple status
> Eric Lemings wrote:
> >  
> > 
> > I agree though: there is a lot of duplication and if it were not for
> > the special pair ctors and assignment operators, there 
> would probably
> > be only one class template.
> Hmm. That's too bad. The prevailing opinion among the C++ committee
> is that pair is exceeding less useful now that we have tuple and that
> it would be best removed or deprecated or some such. It would be a
> shame to compromise the design of type just to accommodate something
> that most of us seem to think is a wart and shouldn't be used. If
> there's just no way to have a clean tuple because of pair we might
> want to formally propose to eliminate the coupling between the two.
> We have at most 2 months to do this.

You could propose this but I very much doubt it would pass, at least in
the upcoming revision of the standard.  It would have a much better
chance of being approved in the subsequent revision of the standard.

My reasoning is this.  The current standard has pairs but no tuples so
existing code that requires such facilities would be, of course, using
pairs.  The next standard will contain tuples and the committee expects
new code to be written with tuples and existing code to MIGRATE to
tuples.  The pair specialization facilitates this migration.  Without
it, there is no migration path.  Now after a decade or so, code would
have enough time to migrate to tuples and a proposal to remove pairs
would more likely be approved for standardization.

> > 
> > Without the cast, the argument type passed to the internal ctor is
> > still `std::tuple<_TypesT...>' and, because of the template ctors,
> > the compiler would therefore bind to the templated copy ctor wisely
> > deeming this ctor a better "fit".
> Would this be prevented by not deriving tuple from __rw_tuple (or
> not deriving it directly)? FWIW, it seems to me that in order to
> implement the space optimization we discussed this morning, we
> might need to make some changes in this area anyway. We should
> keep the cast issue in mind while designing a solution.

I'll have to look into this further but I'm almost certain the changes
required to implement this optimization would make the code even more
complicated and -- if the solution is what I think it may be -- might
even require another base class and possibly more casts.


View raw message