You need a ConcatenatedSequence that joins two sequences without allocating storage

[dabrahams]

This is not fully documented and could use conditional MutableCollection/Equatable/Hashable conformances, but it's a pretty complete implementation that you could use as a starting point.

[mdznr]

Sounds similar to chain(_:_:) in swift-algorithms

[dabrahams]

Ah yes, thanks! FWIW, the division of libraries into Algorithms and Collections doesn’t make a lot of sense to me. I knew I was looking for a collection, so why would I go looking at that other library? I guess Algorithms is where you put all the collection adapters?

…

On Dec 30, 2022, at 9:08 PM, Matt Zanchelli ***@***.***> wrote: Sounds similar to chain(_:_:) in swift-algorithms <https://github.com/apple/swift-algorithms/blob/main/Guides/Chain.md> — Reply to this email directly, view it on GitHub <#258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAKYIP2EEN3AJKUCQ3KCM3WP65UJANCNFSM6AAAAAATNLHMJY>. You are receiving this because you authored the thread.

[mdznr]

A lot of the algorithms in swift-algorithms end up producing a Sequence or Collection of some kind, but unsure if that makes it a good fit for swift-collections. chain is a bit of a weird one since it’s not much of an algorithm in the way that I would think of other algorithms. But it’s also not quite a collection in the way that I’d really only use it ephemerally (like finding the min/max values of two sequences) and not using it to store data longer than that.

I do wonder what the future of the relationship between the two packages is, though. There are algorithms that could benefit from using one of the collections in swift-collections, like Deque and OrderedSet. And there are collections whose implementations could benefit from using an algorithm that would be a good fit for swift-algorithms.

[dabrahams]

I do wonder what the future of the relationship between the two packages is, though.

FWIW, I always thought that a much more granular approach was more appropriate (hence the organization of https://github.com/loftware, which was supposed to end up being more than it is). The idea that there's just one library of Swift algorithms and one library of containers out there is not only unrealistic, but it discourages a vibrant library package ecosystem by making any collection or algorithm hosted elsewhere seem like a second-class citizen. It also contributes to Swift seeming like an Apple thing rather than an open-source thing. Swift really needs a social (if not technical) equivalent of Boost, where separate components are developed and peer-reviewed, but not subject to Apple's gatekeeping, and where new domains can be explored and approved without ceremony.

[lorentey]

FWIW, here is how I look at it:

Swift Collections tends to provide classic general purpose mutable data structures, usually with relatively heavyweight implementations. Clients are expected to import that package to get access to the types themselves. (Something vaguely like collections in Python.)

Swift Algorithms tends to concentrate on lazy or eager implementations of generic operations on the Collection protocol hierarchy. The primary entry points are individual functions. (Something vaguely like itertools in Python.)

Swift Numerics does both types and individual operations; the common theme there is numerical computing.

To me, concatenating two sequences feels more like a sequence operation than a classic data structure; hence the Swift Algorithms package feels like a more appropriate home for it.

[lorentey]

Closing; as @mdznr noted, we already have an implementation of this operation in Swift Algorithms.