P0429R9 A Standard flat_map #5626
Conversation
| \pnum | ||
| Any sequence container\iref{sequence.reqmts} \tcode{C} | ||
| supporting \oldconcept{RandomAccessIterator} can be used |
There was a problem hiding this comment.
This must be referring to C's associated iterator type(s). How can this be improved? For reference:
Any sequence container with random access iterator and supporting operations front(), push_back() and pop_back() can be used to instantiate priority_queue.
-- https://eel.is/c++draft/priority.queue#priqueue.overview-1.sentence-1
There was a problem hiding this comment.
@jwakely, @CaseyCarter: Any thoughts? I don't think this is broken enough to warrant an immediate fix here, but I'm happy to entertain editorial improvement requests.
Yes, there's a mess of interactions here. P2286 adds [assoc.format], the |
See the improved instructions in p2585r1, which is the version being polled at plenary. |
| -> flat_map<@\exposid{iter-key-type}@<InputIterator>, @\exposid{iter-mapped-type}@<InputIterator>, Compare>; | ||
|
|
||
| template<ranges::input_range R, class Compare = less<@\exposid{range-key-type}@<R>>, | ||
| class Allocator> |
There was a problem hiding this comment.
Is this right? What does it mean that the previous template parameter Compare is defaulted, but Allocator isn't, even though both corresponding function parameters are defaulted? Seems like you can't get this to work without defaulting this Allocator: https://godbolt.org/z/fYesrsbMz.
| class Allocator> | |
| class Allocator = allocator<ranges::range_value_t<R>>> |
| class Allocator> | |
| class Allocator = allocator<@\exposid{range-mapped-type}@<R>>> |
I think both suggestions fulfill the corresponding Constraints element.
| class Allocator> | |
| class Allocator = allocator<void>> |
There was a problem hiding this comment.
I think allocator<void> would be just as good. It's going to be rebound anyway.
There was a problem hiding this comment.
@jwakely: are you (= LWG) happy to add a default argument allocator<void> here?
There was a problem hiding this comment.
I don't think that's editorial. Needs a library issue.
How about replacing them with |
jensmaurer
force-pushed
the
motions-2022-07-lwg-6
branch
from
b515acd
to
9d40840
Compare
That would be correct, but I don't think it would improve the specification, as you have to follow an indirection to see what the constraint is actually telling you. Maybe that's OK, as the standard is not a tutorial. |
jensmaurer
force-pushed
the
motions-2022-07-lwg-6
branch
from
cab33fa
to
a1bdd36
Compare
tkoeppe
force-pushed
the
motions-2022-07-lwg-6
branch
from
a1bdd36
to
a418add
Compare
tkoeppe
force-pushed
the
motions-2022-07-lwg-6
branch
2 times, most recently
from
517a65a
to
686dc49
Compare
- Replaced "may" with "can" in notes. - Replace && in constraints with prose "and" to avoid overfull \hbox
The earlier wording of "containers that the user defines" was not retained for new additions to the Standard, and it is needlessly informal. The term "program-defined" was only added recently, whereas the original wording has essentially existed since the beginnig.
tkoeppe
force-pushed
the
motions-2022-07-lwg-6
branch
from
686dc49
to
3096293
Compare
Fixes #5593
Fixes cplusplus/papers#101