This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

3440. Aggregate-paren-init breaks direct-initializing a tuple or optional from {aggregate-member-value}

Section: 22.4.4.2 [tuple.cnstr], 22.5.3.2 [optional.ctor] Status: NAD Submitter: Ville Voutilainen Opened: 2020-05-01 Last modified: 2020-11-09

Priority: 2

View other active issues in [tuple.cnstr].

View all other issues in [tuple.cnstr].

View all issues with NAD status.

Discussion:

For reference, see this gcc bug report.

Constructing a tuple or optional from an element value of an aggregate is broken in C++20. tuple<c> t({val}); and optional<c> t({val}); invoked a non-forwarding constructor before, but now the perfect-forwarding converting constructors are a match, because the element is constructible from {val}. But it's not convertible, so overload resolution chooses the explicit constructor, and the initialization fails.

Tim Song explains the overload resolution in this reflector discussion.

Now that we understand that C++17 called the non-forwarding conversion constructor, and C++20 tries to use the forwarding conversion constructor, we have the solution. SFINAE away the forwarding conversion constructor when it would convert an aggregate.

This also means that tuple<c> t(0); won't work, which is unfortunate because tuple<c>/optional<c> no longer mirrors what c can do. That's okay; in this LWG issue, we first restore feature parity with C++17, and later, as an extension, enable such initializations so that tuple/optional mirrors what c can do in C++20.

The proposed wording below has been implemented and tested.

[2020-05-09; Reflector prioritization]

Set priority to 2 after reflector discussions.

[2020-06-11; LWG Telecon: Status changed: New → LEWG.]

Ask LEWG if it's desirable to make ({val}) work again. Tomasz would prefer it to be explicit e.g. via std::in_place.

[2020-06-23; LEWG Telecon]

POLL: Make ({val}) work again, at the risk of non-transparency of tuple constructors and further complicating the tuple and optional overload set.

SF F N A SA
0  5 6 9 0

No consensus for change. Close as Not a defect.

[2020-11-09 Status changed: Tentatively NAD → NAD.]

Proposed resolution:

This wording is relative to N4861.

1. Modify 22.4.4.2 [tuple.cnstr] as indicated:

   template<class... UTypes> constexpr explicit(see below) tuple(UTypes&&... u);
   

   -11- Constraints: sizeof...(Types) equals sizeof...(UTypes) and sizeof...(Types) ≥ 1 and is_constructible_v<Ti, Ui> is true for all i and conjunction_v<is_aggregate<remove_reference_t<Ti>>, negation<is_same<remove_reference_t<Ti>, remove_reference_t<Ui>>>> is false for all i.

2. Modify 22.5.3.2 [optional.ctor] as indicated:

   template<class U = T> constexpr explicit(see below) optional(U&& v);
   

   -22- Constraints: is_constructible_v<T, U> is true, is_same_v<remove_cvref_t<U>, in_place_t> is false, and is_same_v<remove_cvref_t<U>, optional> is false, and conjunction_v<is_aggregate<T>, negation<is_same<T, remove_reference_t<U>>>> is false.