wash added a comment.
For all the `transform_` variants, the spec allows the "inner" operation (the
transformation)'s return type is not constrained. We should have a test for
this.
For example, consider the binary-unary `transform_reduce` implementation:
template <class _InputIterator, class _Tp, class _BinaryOp, class _UnaryOp>
inline _LIBCPP_INLINE_VISIBILITY
_Tp
transform_reduce(_InputIterator __first, _InputIterator __last,
_Tp __init, _BinaryOp __b, _UnaryOp __u)
{
for (; __first != __last; ++__first)
__init = __b(__init, __u(*__first));
return __init;
}
The standard says the algorithm requires all of the following expressions be
convertible to `_Tp`:
- `__b(__init, __init)`
- `__b(__init, __u(*__first))`
- `__b(__u(*__first), __init)`
- `__b(__u(*__first), __u(*__first))`
So, the following code should be allowed:
struct A {};
struct B {};
struct C {};
B unary_op(C);
A binary_op(A, A);
A binary_op(A, B);
A binary_op(B, A);
A binary_op(B, B);
std::vector<C> v;
std::tranform_reduce(v.begin(), v.end(), A{}, binary_op, unary_op);
Similar cases can be constructed for all the other `transform_` overloads.
I'll try to find time later to put together a concrete test for this.
https://reviews.llvm.org/D33997
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
