A Rope type seems to be present, but undocumented

logancollins · 2023-10-20T18:18:16.793Z

Hello all!

I was randomly browsing through Swift Collections today and noticed that there seems to be a Rope type present in the package, but it also seems to be completely undocumented (besides file comments). It looks to have been added about 6 months ago, from the commits and related pull requests.

I suppose my question is: is this type production-viable at this point, despite it being undocumented? The implementation seems complete from my quick look, but I haven't actually tried to test it with anything yet. If it is ready, was documentation just missed for it, I guess?

github.com

//github.com/apple/swift-collections/tree/main/Sources/RopeModule

scanon · 2023-10-20T19:53:39.418Z

main is an unstable development branch. The current release tag of swift-collections is 1.0.5, which is the current stable API. @lorentey has been working on getting the release/1.1 branch into shape--including writing documentation, which (I think?) includes Rope.

logancollins · 2023-10-20T19:59:13.464Z

Ah, of course. That makes sense. Thank you!

lorentey · 2023-10-21T00:00:39.059Z

Rope is production ready in the narrow sense that AttributedString is using it in production in the variant that recently shipped in Foundation. The implementation is complete inasmuch that it has a real life adopter that is using it to solve a real problem, and it seems to work as we expected it would. The current implementation does have some obvious missing functionality, and (as always) there are some low-hanging performance optimizations yet to be done.

Rope is not ready for general public consumption, though, because its API has not been finalized yet. It isn't even clear to me yet if its API is at the right abstraction level -- in particular, RopeElement being a container type on its own is a major complication that feels too fiddly to consider making public. (This is absolutely crucial for text storage, but it would be a huge source of errors for clients that simply want a persistent array-like container of discrete items.)

My current expectation is that we'll keep Rope underscored, and the package would only expose higher-level container types built on top of it.

The module already includes the BigString type, which is definitely at the right abstraction level to make public. (It's "just" a full reimplementation of String's API.)
It would be nice to pair that with a public BigArray type that would implement a container of discrete Elements. (With support for finding items at a specified offset, as measured by some customizable metric (a simplified version of the RopeSummary and RopeMetric protocols).) AttributedString's attribute storage rope implementation is sort of an exploration towards BigArray. (I just didn't have time to pull it back down into swift-collections yet.)

I think BigString and BigArray would make a quite good story on their own, even without exposing Rope.

(For scheduling, the swift-foundation project serves as an important force pushing things forward, as that package cannot be used in production until it can stop depending on specific swift-collections commits.)

logancollins · 2023-10-24T04:50:21.680Z

Thank you for the deep info! That helps a ton. The main reason I posted in the first place was that I've been toying with writing a Rope implementation for text storage for a bit (mainly as a sort-of benchmarking test) and if one was just there, I'd obviously try it first. So this all gives me good hope and ideas!