Page MenuHomePhabricator

[DO NOT LAND] [libc++] [P2248] "Enabling list-initialization for algorithms"
Needs ReviewPublic

Authored by Quuxplusone on Mar 18 2021, 7:56 AM.


Group Reviewers
Restricted Project

Proof-of-concept implementation of
just for playing around with.

I've commented two places where I think the paper picks the wrong default.
I don't propose to land this patch in libc++ trunk at all; but anyway, even if someone did want to land it, it would need test cases.

Diff Detail

Event Timeline

Quuxplusone created this revision.Mar 18 2021, 7:56 AM
Quuxplusone requested review of this revision.Mar 18 2021, 7:56 AM
Herald added a reviewer: Restricted Project. · View Herald TranscriptMar 18 2021, 7:56 AM
curdeius added inline comments.

Out of curiosity, what's your reasoning on this? Why input output should be preferred?
Do you mean some fancy output iterators that accept any type but e.g. do some counting and, hence, have a different value_type?


Is switching the order necessary? It's not in the paper.
And it's a function template so there is no restriction on parameters following the defaulted one.

Quuxplusone added inline comments.Mar 18 2021, 4:55 PM

Let I be __iter_value_type<_InputIterator> and O be __iter_value_type<_OutputIterator>.

The only thing we do with __old_value is compare it to an object of type I. There's no particular reason to think that I is comparable with O, nor to think that I is comparable with I... but it seems more reasonable to compare I with I than to compare I with O.

The only thing we do with __new_value is assign it into *__result — something we already do with a value of type I (line 2065) but never with a value of type O.

Also consider this contrived example: std::replace_copy(floatpairs.begin(), floatpairs.end(), intpairs.begin(), {1.5, 1.5}, {2,2}).


It's not necessary, but we're free to do it, and I decided I didn't like the look of

, class _Compare>

with that dangling comma.