[libcxx-commits] [libcxx] [libcxx] adds ranges::fold_left_with_iter and ranges::fold_left (PR #75259)

[Christopher Di Bella via libcxx-commits]

================
@@ -0,0 +1,118 @@
+// -*- C++ -*-
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef _LIBCPP___ALGORITHM_FOLD_H
+#define _LIBCPP___ALGORITHM_FOLD_H
+
+#include <__concepts/assignable.h>
+#include <__concepts/convertible_to.h>
+#include <__concepts/invocable.h>
+#include <__concepts/movable.h>
+#include <__config>
+#include <__functional/invoke.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/iterator_traits.h>
+#include <__iterator/next.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__ranges/dangling.h>
+#include <__type_traits/decay.h>
+#include <__type_traits/invoke.h>
+#include <__utility/forward.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+#if _LIBCPP_STD_VER >= 23
+
+namespace ranges {
+template <class _Ip, class _Tp>
+struct in_value_result {
+  _Ip in;
+  _Tp result;
+};
+
+template <class _Ip, class _Tp>
+using fold_left_with_iter_result = in_value_result<_Ip, _Tp>;
+
+template <class _Fp, class _Tp, class _Ip, class _Rp, class _Up = decay_t<_Rp>>
+concept __indirectly_binary_left_foldable_impl =
+    convertible_to<_Rp, _Up> &&                    //
----------------
cjdb wrote:

I agree that we need to be copying verbatim for user-facing concepts. Exposition-only concepts are a different story because:

* they're only present for the purposes of conveying the necessary constraints without needing to open a _Constraints_ element;
* are optimised for communicating information in standardese, not for real-world software engineering;
* can be refactored editorially, meaning that they can silently change and we'd be out of sync without realising

Had this been a _Constraints_ element instead of a concept, we would've needed to construct the concept from prose, and it would look as it does here. I think it would be in our users' best interests to treat exposition-only concepts as a shorthand for a _Constraints_ element instead of something that's set in stone. In this case, it only mildly improves readability, and so it's not really worth debating, but there are other cases where it can actually matter (such as _`indirectly-binary-right-foldable`_, but we can have that discussion when I implement that).

https://github.com/llvm/llvm-project/pull/75259