This is an archive of the discontinued LLVM Phabricator instance.

[RFC][libc++] Allow non-copyable OutputIterators.
AbandonedPublic

Authored by Mordante on Jan 15 2022, 6:35 AM.

Details

Reviewers
ldionne
Quuxplusone
Group Reviewers
Restricted Project
Summary

Starting with C++20 (input and) output iterators. This patch is a
proof-of-concept only modifying one algorithm.

When we're happy with this patch I want look at similar fixes for the
other iterators. (As seen in the build errors there are quite some
places that need fixes.)

Noticed this while working on LWG3539
format_to must not copy models of output_iterator<const charT&>

Depends on D117395

Diff Detail

Event Timeline

Mordante requested review of this revision.Jan 15 2022, 6:35 AM
Mordante created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptJan 15 2022, 6:35 AM
Herald added a reviewer: Restricted Project. · View Herald Transcript
libcxx/include/__config
1084–1094

You don't need this; you should _VSTD::move(__it) unconditionally. Even in C++11, if a type It supports

it = jt;  // OK
it = It(jt);  // compiler error

then it is not an iterator type. Iterators have to be copyable, and that includes movable as a subcondition.
Also, moving is never slower than copying. If C++20 forces us to update some copies to moves, we should do the upgrade unconditionally. (Even in C++03, where _VSTD::move is supported as an extension.)

libcxx/test/support/test_iterators.h
35–42

This is inconsistent with the tactic we picked for input_iterator: We now have a cpp17_input_iterator<T*> and a cpp20_input_iterator<T*> as two differently named types, and we test them both in C++20 mode.
Should we just use this (much simpler) tactic for both output_iterator and input_iterator?
If there's a good reason not to use this tactic for input_iterator, then, does that same good reason apply to output_iterator?

Mordante planned changes to this revision.Jan 15 2022, 9:37 AM

Thanks for the input, I think using std::move is the way forward.

libcxx/include/__config
1084–1094

I forgot we allow _VSTD::move in C++03 mode. That makes this change unneeded and makes the changes a lot simpler. Thanks for the reminder!

libcxx/test/support/test_iterators.h
35–42

It depends on whether Cpp17OutputIterator is used in C++20? If it is we need a second version. This is a quick test to see what fails.

Mordante added inline comments.Jan 22 2022, 7:43 AM
libcxx/test/support/test_iterators.h
35–42

Actually it seems Cpp17OutputIterator is used. The comment for cpp17_input_iterator is misleading. The algorithms still use the same requirements as C++17. D117950 renames the current requirements, making the way free to add new C++20 iterator.

Mordante abandoned this revision.Sep 28 2022, 12:13 PM

With ranges completed there's no need to use pre-C++20 algorithms. Since it will be quite a bit of effort to adjust all algorithms and it has a very low priority I abandon this instead.

Herald added a project: Restricted Project. · View Herald TranscriptSep 28 2022, 12:13 PM