Hacker News new | ask | show | jobs
by adamwk 401 days ago
There’s a section in the proposal about this: https://github.com/swiftlang/swift-evolution/blob/main/propo...

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.
1 comments
saghm 401 days ago
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).
link
adamwk 401 days ago
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.

link
monkeyelite 401 days ago
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.

link