### 2051. Explicit `tuple` constructors for more than one parameter

**Section:** 23.5.3 [tuple.tuple], 23.5.3.1 [tuple.cnstr] **Status:** Resolved
**Submitter:** Ville Voutilainen **Opened:** 2011-05-01 **Last modified:** 2016-02-10

**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:

`pair` allows such a return
- a lambda with a deduced return type doesn't allow it for any type
`decltype` refuses `{1, 2}`

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.