Provide overloads for {Unordered}RangeEquals taking a std::initializer_list#2919
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## devel #2919 +/- ##
=======================================
Coverage 90.99% 90.99%
=======================================
Files 198 198
Lines 8597 8597
=======================================
Hits 7822 7822
Misses 775 775 |
| template <typename T> | ||
| constexpr | ||
| UnorderedRangeEqualsMatcher<std::initializer_list<T>, std::equal_to<>> | ||
| UnorderedRangeEquals( std::initializer_list<T> range ) { |
There was a problem hiding this comment.
I see that this copies the old overloads, but I wonder why I went with overloads instead of defaulted comparison parameter back then.
There was a problem hiding this comment.
I wondered the same, but was reluctant to change it. Now that you mention it, I added a commit (before mine) to clean this up: 5328f90. Sorry for force-pushing, but I didn't want to put a commit on top that changes it both for the existing code and the new overloads; the diffs are much cleaner this way.
horenmar
left a comment
horenmar
left a comment
There was a problem hiding this comment.
I am going to look into the overload vs default argument a bit later, but the PR looks good.
…ed}RangeEquals Saves some code duplication.
…r_list
This allows writing something like
const auto v = calculateSomeVectorOfInts();
CHECK_THAT(v, RangeEquals({1, 2, 3}));
Fixes catchorg#2915.
stk-ableton
force-pushed
the
support-initializer-list-with-RangeEquals
branch
from
1c6a187 to
ef2f8fb
Compare
|
The default args should be fine here. The usual arguments against should not apply to this use case. Thanks for the change. |
2 participants
This allows writing something like
Fixes #2915.