tomaszkam

Confirmed that all affected algorithms are still well-formed, as they are calling `invoke(invoke(proj1, first1), invoke(proj2, first2))`. This includes once that are constrained with `IndirectlyComparable`: * split_view, * find_end, * equal,...

Added Equivalence and IndirectEquivalence relation that are now used to constrain the following algorithms: * is_permutation * unique and unique_copy

>> EDIT: I'll also note that once the range-based relational operators and common_type specializations are added to the proposal, the STL2 solution to this problem is much shorter and easier...

Few things regarding the request: 1) The code has UB, as a comparison of any_view does not match the comparison of the algorithms, i.e. the semantics requirements of StrictWeakOrdering are...

The fact is I am unable to reproduce your result on my system. I am using g++-7: ```Using built-in specs. COLLECT_GCC=g++-7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v...

Yes, the difference is caused by the usage of -O2 vs -O3, however, the apps I have contact with consistently use O2, for them, we are seeing performance drop caused...

Putting -NDEBUG with -O2 does not help: ```> g++-7 -O2 -DNDEBUG -std=c++17 -fconcepts itinerary.cpp -Icmcstl2/include/ -lbenchmark -lpthread > ./a.out 2018-08-07 21:37:03 Running ./a.out Run on (8 X 4200 MHz CPU...

> Is that with itinerary.cpp from #182? I can't explain the differences we're seeing from the same command line and almost precisely the same compiler. I used `itinerary.cpp` from this...

> @tomaszkam One other suggestion for your paper: rather that simply dropping the CommonReference syntactic requirements, you could make it a purely semantic requirement instead. Appeal to the existence of...

I am willing to assume that actually the difference on the result for the test example, is fault on my side. I am also planning to check it on AMD...