Hacker News Reader

Comment by mgaunard | Hacker News Reader

If the value semantics aren't customizable, you can't really build abstractions. How would you even implement std::list?

Ultimately Swift is dependent on having all significant abstractions be built as part of the language-enabled standard library.

View on HN

    enum List<T> { case empty; indirect case cons(T, List<T>) }

std::list (that is, a linked list) is pretty easy to write. Whether you want it to be a reference type or copy-on-write or a Collection (probably very difficult) is up to you. There’s not much that’s special in the standard library.

std::list is a value type which copies the underlying elements on copy.

This is how most Swift Collections work as well

Yet not something that can be written in pure Swift.

What makes you think this?

The problem is you cannot implement a reference type without dropping to UnsafePointer or use class. But using class is so discourage nowadays people probably would be better served by adding an Arc / Ref type wrapper like Rust did.

Use of class was strongly discouraged in the Swift world until they rolled out their new Observation framework for SwiftUI that requires using classes for modeling state and depends on two-way data binding to work. So all the arguments we've been hearing for years about the benefits of structs, immutable data, and controlled updates got tossed out the window.

This was bad timing with the switch to strong concurrency checking in Swift 6 because doing strong concurrency handling in a world of reference types and two way binding is really painful.

I don’t see why you shouldn’t use a class for this

Reply on news.ycombinator.com