> InlineArray does not conform to either Sequence or Collection
Why not? Does this mean I need to make a struct which wraps InlineArray and implements Collection? Why didn't they do that?
EDIT: found the answer (I still have concerns):
> While we could conform to these protocols when the element is copyable, InlineArray is unlike Array in that there are no copy-on-write semantics; it is eagerly copied. Conforming to these protocols would potentially open doors to lots of implicit copies of the underlying InlineArray instance which could be problematic given the prevalence of generic collection algorithms and slicing behavior. To avoid this potential performance pitfall, we're explicitly not opting into conforming this type to Sequence or Collection.
Tl;dr: Sequence and Collection are incompatible with noncopyable types and conditionally conforming when elements are copyable would result in too many implicit copies. They’re working on protocols to cover noncopyable collections such as this, which will probably have a similar API shape.
Interesting; if I'm understanding correctly, it sounds like Swift doesn't have a standard lazy iteration API yet? I would have guessed that it did if asked before reading this, but it's good to hear that they're already working on it. Since I feel super spoiled by lazy iterators in Rust, I'm super curious if anyone has more Swift experience and could chime in on if there are other language features or APIs that might illuminate why there wasn't as much of a need for this earlier; my general perception of Swift as an outsider is that it tends to have pretty well-thought out decisions based on factors that I just happen not to know about personally (e.g. compatibility with other parts of the Apple software ecosystem or different priorities due to the domains Swift is often used in compared to the type of stuff I work on personally).
There are lazy collections, but they’re not default.
Why the protocols are designed the way they are is until very recently all types were implicitly copyable, but most of the collection types like array and dictionary were copy on write; so the copies were cheap. I think in general, though, there are a lot of performance footguns in the design, mainly around when copies aren’t cheap. The future protocols will hopefully rectify these performance issues.
Yeah - super weird. It’s like they saw a nice way to avoid thinking about ownership and references, and now have to reconcile with the real problem.
All of these “replace C++” projects have been quite disappointing. Where they tried to make big simplifications they often just didn’t understand the original problem and inherent complexity - or they made a good, but opinionated design choice which has been unable to survive bureaucratic demand for more features, etc.
Why not? Does this mean I need to make a struct which wraps InlineArray and implements Collection? Why didn't they do that?
EDIT: found the answer (I still have concerns):
> While we could conform to these protocols when the element is copyable, InlineArray is unlike Array in that there are no copy-on-write semantics; it is eagerly copied. Conforming to these protocols would potentially open doors to lots of implicit copies of the underlying InlineArray instance which could be problematic given the prevalence of generic collection algorithms and slicing behavior. To avoid this potential performance pitfall, we're explicitly not opting into conforming this type to Sequence or Collection.