| Doc. no. | Dxxxx=xx-xxxx |
| Date: | 2008-08-25 |
| Project: | Programming Language C++ |
| Reply to: | Douglas Gregor <doug.gregor@gmail.com> |
Also see:
This document contains only concepts issues which have been closed by the concepts authors as duplicates or not defects. That is, issues which have a status of Dup or NAD. See the Concepts Active Issues List active issues and more information. See the Concepts Defect Reports List for issues considered defects. The introductory material in that document also applies to this document.
Section: 20.1.5 [concept.copymove] Status: NAD Submitter: LWG Date: 2008-02-27
View all other issues in [concept.copymove].
View all issues with NAD status.
Discussion:
Substantive issue in MoveAssignable: the postcondition is that the constructed T object is equivalent to the old value of rv. What does equivalent mean? It's especially problematic when U and T are different types, but even for the same type it's not a defined term and not completely clear how it should be defined. (One might imagine that for the same type it should be defined in terms of operator==, but this concept doesn't mention that operator.)
Doug Gregor: the requirements on the move-assignment operator come directly from the corresponding table in the pre-concepts Working Paper, so this issue wasn't introduced by concepts.
Section: 20.1.5 [concept.copymove] Status: Dup Submitter: LWG Date: 2008-02-27
View all other issues in [concept.copymove].
Discussion:
Is Swappable right, or does it also need a T&& signature? We think that Swappable does need to cover rvalue reference and that this concept probably needs to be changed, especially in light of this week's tinkering with swap and Swappable (LWG issue 742), but (a) Nobody in the room understands rvalue references well enough to say for sure, and (b) We aren't sure whether the relaxed signature checking from Tuesday night has any impact. We think the answer might be to put in one T& signature, and two other signatures that default to the first.
Proposed resolution:
Superceded by issue 35.
Section: 20.1.7 [concept.regular] Status: NAD Submitter: LWG Date: 2008-02-27
View all other issues in [concept.regular].
View all issues with NAD status.
Discussion:
Exactly why does Semiregular exist, and what's the design criterion for deciding which of the requirements in Regular should be relaxed for Semiregular? Matt's first thought was that Semiregular was there to describe the "almost regular" value type of std::map, but that's wrong; in this terminology map's value type is neither Regular nor Semiregular. Mat wonders whether there are any algorithms that need to distinguish between Regular and Semiregular. A preliminary search shows no use of it in the latest revision of the concepts-in-clause-25 paper. Can we get rid of Semiregular? (Note: Semiregular is used in the definition of the InputIterator concept.)
Proposed resolution:
Semiregular can be very useful for describing types that used in valarray and complex, if we add DefaultConstructible and Addressable to it. Semiregular then describes types that can be initialized and assigned in a natural way, and from there we add equality into Regular.
Change the definition of Semiregular in [concept.regular] as follows:
auto concept Semiregular<typename T>
: CopyConstructible<T>, CopyAssignable<T>, HeapAllocatable<T>, DefaultConstructible<T>, Addressable<T> {
requires SameType<CopyAssignable<T>::result_type, T&>;&&
SameType<Addressable<T>::pointer, T*> &&
SameType<Addressable<T const>::pointer, T const*>
requires EqualityComparable<T>
axiom InitializationConsistency(T x) {
(T() = x) == T(x);
}
}
Add the following paragraph after the description of Semiregular in [concept.regular]:
[ Example: An implementation is allowed to initialize data by allocating storage using the new operator (which implies a call to the default constructor for the element) and then assigning each element its value. Or the implementation can allocate raw storage and use the copy constructor to initialize the element. -- end example ] -- end note]
Change the definition of the Regular concept in [concept.regular] as follows:
auto concept Regular<typename T> : Semiregular<T>, DefaultConstructible<T>, EqualityComparable<T> { }
Modify the definition of the InputIterator concept in [input.iterators] as follows:
concept InputIterator<typename X> :Semiregular<X>,CopyConstructible<T>, CopyAssignable<T>, HeapAllocatable<T>, EqualityComparable<X> { requires SameType<CopyAssignable<T>::result_type, T&>; // ... }
Section: 20.1.11 [concept.arithmetic] Status: NAD Submitter: LWG Date: 2008-02-27
View all other issues in [concept.arithmetic].
View all issues with NAD status.
Discussion:
Do we really need ArithmeticLike or IntegralLike? They're ugly concepts that don't correspond to any mathematical definition, and the requirement of convertibility from long long is a bit weird. The current clause 25 proposal uses IntegralLike, but maybe it doesn't really need it. Probably those algorithms could be expressed either as real live integer types, built-in types only, or as types that describe an abelian group. IntegralLike, complete with things like &&=, seems both too constraining and too fuzzy.
Section: 24.1 [iterator.concepts] Status: NAD Submitter: LWG Date: 2008-02-28
View all other issues in [iterator.concepts].
View all issues with NAD status.
Discussion:
We're saying that InputIterator is Semiregular and EqualityComparable, instead of just plain Regular. The main reason: in C++03, input iterators aren't necessarily default constructible. (In n2502, Regular just adds DefaultConstructible and HeapAllocatable. But HeapAllocatable is a pretty minor thing, and it isn't discussed in C++03 one way or the other.) Wouldn't it be nice if we could just say Regular instead? Two options: (1) Say Regular and everything it implies in n2502. This implies that all input iterators will be default constructible, which is an incompatibility and a stricter requirements than we have in C++03. It will render some user-defined iterators nonconforming, but maybe that's a small price to pay. (2) Get rid of the Semiregular concept, but remove DefaultConstructible from Regular. Arguably default construction isn't a fundamental part of the notion of regularity, and on the occasions that we want "regular and default constructible" we should say so explicitly.
Proposed resolution:
Adding the default-constructibility requirements breaks some existing input iterators and does not simplify much algorithm code.
Section: 24.1.1 [input.iterators] Status: NAD Submitter: LWG Date: 2008-02-28
View all other issues in [input.iterators].
View all issues with NAD status.
Discussion:
InputIterator currently requires that its difference type be both an IntegerType and SignedIntegralLike. There are two issues here. First, why do we need to require both? Answer: one of those is a compiler-generated concept saying that it must be one of a specific list of built-in types, but it doesn't declare anything about the operations, so it doesn't allow you to actually write things like +. But that's very weird. If we know that we've constrained it to be one of a small number of types, shouldn't we be able to use those operations that those types all have in common? Second, just why are we requiring it to be one of the types in that list? If I have my own type that I can use for counting (i.e. an abelian group), then why can't I use it for the iterator's difference type?
Proposed resolution:
The LWG has reaffirmed that thedifference_type should
be a built-in integral type, since this requirement was present in
the C++98 library. Moreover, the two concepts cannot be fully
combined without some tangling of the compiler-supported concepts
and the library-defined concepts.
Section: 20.1.8 [concept.convertible] Status: NAD Submitter: LWG Date: 2008-02-28
View all issues with NAD status.
Discussion:
The order of argument in Convertible and Constructible is different. We should consider changing the name and/or argument order of Convertible to make it clearer which argument goes where.
Proposed resolution:
The argument order of Convertible matches that of
the is_convertible type trait, and also fits with the
common rewrite of a prefix operator as an infix operator,
e.g., Convertible<T, U> means T
convertible to U. LWG decided not to make this change.
HasCopyAssign should be named HasCopyAssignmentSection: 20.1.10 [concept.operator] Status: NAD Submitter: LWG Date: 2008-06-09
View all other issues in [concept.operator].
View all issues with NAD status.
Discussion:
To match the naming scheme of the other operator
concepts, HasCopyAssign should be
named HasCopyAssignment and HasMoveAssign
should be named HasMoveAssignment.
Proposed resolution:
The LWG decided to keep the shorter name, particularly because
names like HasModulusAssignment were getting far too
long.