[libc-commits] [libc] [libc][wctype] Upstream custom slice implementation from PtrHash-cc prototype to LLVM libc (PR #174779)

Muhammad Bassiouni via libc-commits libc-commits at lists.llvm.org
Fri Jan 9 09:58:24 PST 2026


================
@@ -0,0 +1,117 @@
+//===-- Internal utils for wctype conversion code - slice -------*- 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
+//
+//===----------------------------------------------------------------------===//
+// Similar to cpp::span with additional functionality
+
+#ifndef LLVM_LIBC_SRC___SUPPORT_WCTYPE_CONVERSION_UTILS_SLICE_H
+#define LLVM_LIBC_SRC___SUPPORT_WCTYPE_CONVERSION_UTILS_SLICE_H
+
+#include "hdr/types/size_t.h"
+#include "src/__support/CPP/algorithm.h"
+#include "src/__support/CPP/expected.h"
+#include "src/__support/CPP/span.h"
+#include "src/__support/libc_assert.h"
+
+namespace LIBC_NAMESPACE_DECL {
+
+namespace wctype_internal {
+
+namespace conversion_utils {
+
+enum class Ordering {
+  /// An ordering where a compared value is less than another.
+  Less = -1,
+  /// An ordering where a compared value is equal to another.
+  Equal = 0,
+  /// An ordering where a compared value is greater than another.
+  Greater = 1,
+};
+
+template <typename T> struct Slice : public cpp::span<T> {
----------------
bassiounix wrote:

> Well yeah, I just meant inheritance might not be the cleanest way to handle this.

I need the same interface of `cpp::span` with my additional functionality, that's why I did it with inheritance.

> range: `cpp::span` already has subspan, which is similar

I didn't notice that! Thanks for pointing it out.
However, `range` returns a `Slice` not `cpp::span` which (`Slice`) is heavily used by he prototype code with its additional functionality as a wrapper over `cpp::span`. I can rename it to something like `slice_form_range`.

> `binary_search_by` and `contains` could be freestanding (similar to `std::upper/lower_bound`, `std::ranges::contains`)

I agree, however I don't see those implementations yet in `algorithm.h` and I want to keep the `Slice`'s interface as is. I could factor out the internal implementation to free functions, but I think this is out of scope of this PR. Once those changes are needed by other maintainers out of the scope of wctype conversion function and an implementation is available, I can then use those free functions inside these methods.

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


More information about the libc-commits mailing list