5 ms·
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 havin
by mgaunard 3y ago
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.
- cobbal 3y agoenum List<T> { case empty; indirect case cons(T, List<T>) }
- saagarjha 3y agostd::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.
- mgaunard 3y agostd::list is a value type which copies the underlying elements on copy.
- liuliu 3y agoThe 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.
- saagarjha 3y agoI don’t see why you shouldn’t use a class for this
- cageface 3y agoUse 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.