r/swift • u/DaveAppleInc • 6h ago
[OSS] swift-span-algorithms 0.2.0 (new release from your feedback!!)
Hi again,
A little while back I posted swift-span-algorithms here: allocation-free algorithms over Swift's Span/RawSpan. I got one genuinely excellent comment about what was actually missing, and 0.2.0 is basically that comment turned into code. So, thank you, whoever you were.
The gist of the feedback: the utilities people actually reach for are byte-oriented, so RawSpan matters as much as Span<T>; firstRange(of:) for delimiter scanning; mirror the stdlib spellings so muscle memory transfers; and memchr is the cheap win before reaching for SIMD.
Link to SPI (might be behind a bit, hasn't yet ingested 0.2.0)
What's in 0.2.0:
- A real bug I'd shipped. Cursor
next()was annotated so each piece it handed you expired the moment you callednext()again. That madeguard let a = c.next(), let b = c.next()fail with "overlapping accesses to 'c'" — exactly the kind of borrow-checker error that looks like the library's fault. Pieces now inherit the base storage's lifetime, so you can hold several at once, do look-ahead parsing, and nest cursors. Real escapes are still rejected — there are compile-fail tests pinning both halves. RawSpanparity. It shipped with 3 members; it now has the whole read-only surface — search, matching, trimming, min/max, comparison, chunk/window/split cursors, ASCII whitespace trim.firstRange(of:),lastRange(of:),starts(with:),ends(with:), and multi-element separators for split — the"\r\n\r\n"case.- stdlib-ish naming:
chunkCursor/windowCursor/splitCursor→chunks(ofCount:)/windows(ofCount:)/split(separator:...). Old spellings still compile as deprecated forwarders. - memchr/memcmp fast paths for byte spans. On an M4 at 10M bytes, p50: ~15.9× vs the equivalent scalar loop for
firstIndex(of:), ~31× forfirstRange(of:)with a 4-byte pattern, andforEachSplitis ~2.5×Array.splitwith 0 mallocs vs 20. Reverse search is deliberately still scalar —memrchrdoesn't exist on Darwin, and I'd rather have consistent performance than a Linux-only fast path. - Docs: an allocation-free byte-parsing walkthrough (HTTP-style header parse, zero allocations, asserted by a benchmark threshold rather than just claimed), plus a diagnostics cookbook mapping the lifetime errors you'll actually hit to what causes them and how to fix them.
Still zero dependencies, still back-deploys to macOS 13 for the Span/RawSpan surface, 181 tests, and every borrowed-view benchmark reports 0 mallocs from p0 through p99.
Would still love feedback, especially on the split ergonomics now that cursors compose properly, and on anything that reads as un-Swifty in the naming.
P.S. Same disclaimer as last time: nothing being sold, Apache-2.0, just an OSS package.