This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 22.4.4 [tuple.tuple], 22.4.4.1 [tuple.cnstr] Status: Resolved Submitter: Ville Voutilainen Opened: 2011-05-01 Last modified: 2016-01-28
Priority: 2
View all other issues in [tuple.tuple].
View all issues with Resolved status.
Discussion:
One of my constituents wrote the following:
-------snip------------ So far the only use I've found for std::tuple is as an ad-hoc type to emulate multiple return values. If the tuple ctor was made non-explicit one could almost think C++ supported multiple return values especially when combined with std::tie().// assume types line_segment and point // assume function double distance(point const&, point const&) std::tuple<point, point> closest_points(line_segment const& a, line_segment const& b) { point ax; point bx; /* some math */ return {ax, bx}; } double distance(line_segment const& a, line_segment const& b) { point ax; point bx; std::tie(ax, bx) = closest_points(a, b); return distance(ax, bx); }
-------snap----------
See also the messages starting from lib-29330. Some notes:I would recommend making non-unary tuple constructors non-explicit.
[Bloomington, 2011]
Move to NAD Future, this would be an extension to existing functionality.
[Portland, 2012]
Move to Open at the request of the Evolution Working Group.
[Lenexa 2015-05-05]
VV: While in the area of tuples, LWG 2051 should have status of WP, it is resolved by Daniel's "improving pair and tuple" paper.
MC: status Resolved, by N4387
Proposed resolution:
Resolved by the adoption of N4387.