Created on 2014-02-19.00:00:00 last changed 90 months ago
Proposed resolution:
This wording is relative to N3936.
Change [pairs.pair] around p3 as indicated:
constexpr pair();-4- Effects: Value-initializes first and second. -?- Remarks: This constructor shall not participate in overload resolution unless is_default_constructible<first_type>::value is true and is_default_constructible<second_type>::value is true. [Note: This behaviour can be implemented by a constructor template with default template arguments — end note].
-3- Requires: is_default_constructible<first_type>::value is true and is_default_constructible<second_type>::value is true.
Change [tuple.cnstr] around p4 as indicated:
constexpr tuple();-5- Effects: Value initializes each element. -?- Remarks: This constructor shall not participate in overload resolution unless is_default_constructible<Ti>::value is true for all i. [Note: This behaviour can be implemented by a constructor template with default template arguments — end note].
-4- Requires: is_default_constructible<Ti>::value is true for all i.
[ 2015-05, Lenexa ]
STL: I object to this resolution due to British spelling of behavior
JW: we already have other places of this spelling
VV: the easy resolution is to remove the notes
MC: if that's all we want to change: put it in and make the editorial change of removing the note
VV: the other paper doesn't make any of these changes so it would be consistent
JW: this make me want even more the features of having constructors doing the Right Thing
- I haven't written up the request to do something like that
VV: so it would be an aggregate reflecting the properties of the constituting types
JW: I should write that up
MC: any objection to move to ready? in favor: 16, opposed: 0, abstain: 1
[ 2014-05-14, Daniel comments ]
The proposed resolution is incomplete, because it wouldn't work for cv-qualified objects of pair or for references of them during reference-initialization.
I would like to point out that the approach suggested in N3739 can be easily extended to solve the problem without need to muddle with specializing is_constructible:template<class U1 = T1, class U2 = T2, typename enable_if< is_default_constructible<U1>::value && is_default_constructible<U2>::value , bool>::type = false > constexpr pair();
The new wording proposal represents an alternative wording change that I would strongly prefer.
Previous resolution from Howard [SUPERSEDED]:This wording is relative to N3936.
Add to [pairs.spec]:
template <class T, class U> struct is_constructible<pair<T, U>> : integral_constant<bool, is_default_constructible<T>::value && is_default_constructible<U>::value> {};Add to [tuple.special]:
template <class ...T> struct is_constructible<tuple<T...>> : integral_constant<bool, see below> {};-?- The second argument to integral_constant shall be true if for each T, is_default_constructible<T>::value is true.
Consider:
struct X { X() = delete; }; int main() { typedef std::pair<int, X> P; static_assert(!std::is_constructible<P>::value, ""); static_assert(!std::is_default_constructible<P>::value, ""); typedef std::tuple<int, X> T; static_assert(!std::is_constructible<T>::value, ""); static_assert(!std::is_default_constructible<T>::value, ""); }
For me these static_asserts fail. And worse than that, even asking the question fails (as opposed to gets the wrong answer):
assert(!std::is_constructible<P>::value);
In file included from test.cpp:2:
error: call to deleted constructor of 'X' pair() : first(), second() {} ^ note: function has been explicitly marked deleted here X() = delete; ^ 1 error generated.
This can be solved by specializing is_constructible on pair and tuple for zero Args:
template <class T, class U> struct is_constructible<pair<T, U>> : integral_constant<bool, is_default_constructible<T>::value && is_default_constructible<U>::value> {}; template <class ...T> struct is_constructible<tuple<T...>> : integral_constant<bool, __all<is_default_constructible<T>::value...>::value> {};
Now everything just works.
History | |||
---|---|---|---|
Date | User | Action | Args |
2017-07-30 20:15:43 | admin | set | status: wp -> c++17 |
2015-10-27 16:52:45 | admin | set | status: ready -> wp |
2015-05-07 23:01:40 | admin | set | messages: + msg7386 |
2015-05-07 23:01:40 | admin | set | status: new -> ready |
2014-05-14 21:21:48 | admin | set | messages: + msg6944 |
2014-03-24 21:23:12 | admin | set | messages: + msg6908 |
2014-02-19 00:00:00 | admin | create |