Comments on: Requirement Propagation and CopyConstructible

By: gfaraj

gfaraj — Tue, 08 May 2007 15:33:05 +0000

Thanks for the clarification Douglas. I understand now the reasoning of removing the compiler-generated requirements. It does make sense and goes along with the usual desire of the C++ community to reduce the amount of coupling between the language and the standard library. Thanks again.

By: Douglas Gregor

Douglas Gregor — Tue, 08 May 2007 13:38:30 +0000

Sorry, I wrote up all of the rationale behind the removal of this feature in a note to the C++ committee, but did not include the motivation here. Here’s an excerpt with the motivation for this decision:

Previously (and in ConceptGCC), we propagated the requirement
std::CopyConstructible for argument and return types. With the
introduction of rvalue references, we changed this to
std::MoveConstructible, because one can move values into arguments
and out of the return type. This change has exposed two issues:

1) Users—not the compiler—should be deciding between
MoveConstructible and CopyConstructible.

2) If future changes to C++ mean that one can construct arguments
without requiring a copy or move constructor, we would either
have our templates over-constrained, or we would have to break
code that relies on requirement propagation. Both are bad
outcomes.

Due to these problems, and the coupling of the MoveConstructible
concept with the compiler, we want to remove requirement propagation
of MoveConstructible from argument and return types in a declaration.

By: Niels Dekker

Niels Dekker — Sat, 05 May 2007 09:20:28 +0000

Thanks for your information, Doug! Like gfaraj, I’d be interested to know why this “requirement propagation” had to be removed. It seemed to me like a very convenient feature! But you got me even more confused, because your quote from N2193, [temp.req.prop] paragraph 2, differs slightly from the paper at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2193.pdf

n2193.pdf says:
bool eq(T x, T y); // implicitly adds requirement MoveConstructible

Do you agree that once the MoveConstructible concept is included with ConceptGCC, ‘T negate(const T&)’ should require MoveConstructible, instead of CopyConstructible?

By: gfaraj

gfaraj — Sat, 05 May 2007 06:14:43 +0000

Wait… I’m a little confused. Why doesn’t ConceptGCC compile the negate template as firstly shown? Why do we need to specify the CopyConstructible requirement, when the return type of negate implicitly states that T must be copy constructible? Maybe I’m misunderstanding the post, can someone clarify, please? Thanks!