`<ranges>`: `chunk_by_view`'s helper lambda does not specify return type

[hewillk]

STL/stl/inc/ranges

Lines 6258 to 6260 in ef62d3f

	const auto _Not_pred = [&_Orig_pred = *_Pred]<class _Ty1, class _Ty2>(_Ty1&& _Left, _Ty2&& _Right) {
	return !_STD invoke(_Orig_pred, _STD forward<_Ty1>(_Left), _STD forward<_Ty2>(_Right));
	};

STL/stl/inc/ranges

Lines 6272 to 6274 in ef62d3f

	const auto _Rev_not_pred = [&_Orig_pred = *_Pred]<class _Ty1, class _Ty2>(_Ty1&& _Left, _Ty2&& _Right) {
	return !_STD invoke(_Orig_pred, _STD forward<_Ty2>(_Right), _STD forward<_Ty1>(_Left));
	};

This is basically the same problem as #2888.
I don't know how to use MSVC-STL-trunk with Compiler Explorer, but the following code should be rejected incorrectly.

#include <ranges>

struct Bool {
  Bool& operator!();
  Bool() = default;
  Bool(const Bool&) = delete;
  operator bool() { return true; };
};

int main() {
  Bool b;
  int x[] = {42};
  auto r = std::views::iota(0, 5) | std::views::chunk_by([&](auto, auto) -> Bool& { return b; });
  r.begin();
}

[strega-nil-ms]

Mmh, actually now that I look at the standard wording, I disagree with this issue being a bug. The specification of find-next is:

ranges::next(ranges::adjacent_find(current, ranges::end(base_), not_fn(ref(*pred_))),
             1, ranges::end(base_))

(this being [range.chunk.by.view]/8)

The definition of not_fn ([func.not.fn]) says it "Returns: A perfect forwarding call wrapper ([func.require]) g with call pattern !invoke(fd, call_­args...)", i.e., that it exactly returns the return type of !invoke(fd, call_args...), and thus adjacent_find will use that type, not bool, to do whatever it does.

In theory, we could make this an LWG issue, but as it is right now it is certainly not a bug.

[hewillk]

The definition of not_fn ([func.not.fn]) says it "Returns: A perfect forwarding call wrapper ([func.require]) g with call pattern !invoke(fd, call_­args...)", i.e., that it exactly returns the return type of !invoke(fd, call_args...), and thus adjacent_find will use that type, not bool, to do whatever it does.

Then lambda needs to specify return type -> decltype(auto), which is equivalent to ->bool, which will work.

[CaseyCarter]

[func.require]/5: "A postfix call performed on a perfect forwarding call wrapper is expression-equivalent ([defns.expression.equivalent]) to an expression e determined from its call pattern cp by replacing all occurrences of the arguments of the call wrapper and its state entities with references as described in the corresponding forwarding steps."

e might be a glvalue, in which case expression-equivalence requires the return type of the perfect forwarding call wrapper to be decltype(e) and not decay_t<decltype(e)> as is the case for _Rev_not_pred. As Hewill Kang (@hewillk) says, the simplest fix is for the lambda to return decltype(auto).

[strega-nil-ms]

Mmh, point; so in other words, the issue is correct, but the PR is incorrect.

[hewillk]

No, the PR is correct. As I said, the two are equivalent because the return type is converted to bool anyway.