Objective-C ARC (automatic reference counting) solved the problem neatly for my iOS apps.
Is there some overhead? Maybe, but it's neatly spread out through the entire application life time, so there is rarely[1] a UI-freezing stutter associated with GC. To reduce the overhead I turned off thread-safety and simply never access the same objects from more than one thread (object has to be "handed off" first if it comes to that).
One wart on the body of ARC is KVO, which I avoid like a plague for many other reasons anyway.
The other wart is strong reference loops. This can be solved by the app developer by designing architecture around the "ownership" concept (owners use strong references to their ownees, all other links are weak references). This is a good idea in itself as it increases clarity of the program. I do make an occasional slip, which is where I need to rely on Instruments, and I do wish I had better tools than that, something more automatic that would catch me in the act. Maybe a crawler that looks for loops in strong references during the development process but is quiet in release builds. Or at least give me a pattern to follow that makes it easy to catch my errors. For example, we could assign a sequential number to each allocated object, and only higher-ranked object could strongly refer to lower-ranked object. This won't work for everyone but I wouldn't mind fitting my app to this mold if that gave me immediate error when I slip.
[1] if you release a few million objects all at once it may stutter for a second. Could be handed off to a parallel thread maybe.
True! And ARC in Rust suffers from the same problem (note that while ARC in Rust and ARC in Swift are the same thing, the "A" happens to stand for different words in each case).
Hi! I think you may have repeated what I said in my comment, that the letter "a" stands for different things. Although they do the same thing: they are both atomic (in the sense of concurrency) and automatic (in the sense that you do not have to explicitly retain or release objects).
It sounds automatic to me. Maybe we disagree about what "automatic" is.
It also sounds like you are hunting for ways in which Swift and Rust are different. This is completely unnecessary! It turns out that I already know that they are different languages, and that the features do not map exactly 1:1 to each other. I hope next time you give me a little credit.
> I do make an occasional slip, which is where I need to rely on Instruments, and I do wish I had better tools than that, something more automatic that would catch me in the act.
Xcode's debug toolbar has a "debug memory graph" button that will visualize the object graph for your entire program. Reference cycles are automatically detected and listed in the issue navigator.
Is there some overhead? Maybe, but it's neatly spread out through the entire application life time, so there is rarely[1] a UI-freezing stutter associated with GC. To reduce the overhead I turned off thread-safety and simply never access the same objects from more than one thread (object has to be "handed off" first if it comes to that).
One wart on the body of ARC is KVO, which I avoid like a plague for many other reasons anyway.
The other wart is strong reference loops. This can be solved by the app developer by designing architecture around the "ownership" concept (owners use strong references to their ownees, all other links are weak references). This is a good idea in itself as it increases clarity of the program. I do make an occasional slip, which is where I need to rely on Instruments, and I do wish I had better tools than that, something more automatic that would catch me in the act. Maybe a crawler that looks for loops in strong references during the development process but is quiet in release builds. Or at least give me a pattern to follow that makes it easy to catch my errors. For example, we could assign a sequential number to each allocated object, and only higher-ranked object could strongly refer to lower-ranked object. This won't work for everyone but I wouldn't mind fitting my app to this mold if that gave me immediate error when I slip.
[1] if you release a few million objects all at once it may stutter for a second. Could be handed off to a parallel thread maybe.