[libcxx-commits] [PATCH] D149827: [libc++][ranges] Implement the changes to `deque` from P1206 (`ranges::to`):

[Konstantin Varlamov via Phabricator via libcxx-commits]

var-const added a subscriber: jwakely.
var-const added inline comments.


================
Comment at: libcxx/include/__algorithm/copy_n.h:42
         *__result = *__first;
+        ++__first;
         ++__result;
----------------
ldionne wrote:
> I think this needs a LWG issue.`std::copy_n` and `ranges::copy_n` have the exact same specification (http://eel.is/c++draft/alg.copy#lib:copy_n), but `std::copy_n` seems to be expected not to increment the input iterator if it can avoid it. `ranges::copy_n` does increment the iterator. For something like `istream_iterator`, this means we will be extracting different numbers of elements from the underlying stream.
> 
> This feels similar to the `views::take` issue we discussed in Issaquah, it might be worth checking whether that issue did talk about `copy_n` as another case of the same problem.
> 
> But for certain, I think we'll break users if we start increment this here, so we shouldn't do it unless we're blessed by the standard explicitly.
Digging through the list of LWG issues, this has been raised before ranges as http://wg21.link/lwg2471. Ranges do make the issue more noticeable, though, because now the discrepancy is not just between `copy_n` and `uninitialized_copy_n`, but also `copy_n` and `ranges::copy_n`. It doesn't look like there's been any update on the issue, though.

@jwakely Were there any updates on this issue? I seem to remember this issue being brought up in Issaquah, but I couldn't find anything in LWG notes, so I might be confusing this with something. I can file a new LWG issue to talk specifically about the discrepancy between `copy_n` and `ranges::copy_n` -- do you think it makes sense?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149827/new/

https://reviews.llvm.org/D149827