in 2023, swift still doesn't have a tracing GC, and they are still using reference counting to decide when to deallocate an instance, surprise! what's even worse is closures are everywhere and the default way to define a closure make it possible to keep a reference to variables in the parent scope.

Dang. At work I feel like a hotshot since I seem to know quite a bit compared to average.

Then I come to devrant and everyday I'm being reminded how much I don't know

Dude it’s automatic reference counting and it is a design decision. The compiler does it for you. Garbage collectors have a couple of disadvantages like performance and indeterminism. The only downside of automatic reference counting is that you need to be careful sometimes not to cause reference cycles but there is the "weak" keyword for that. And it’s only necessary for reference types. The benefits are worth the small downside.

Unless I'm mistaken, you are still fully free to use objective c and turn off ARC if you'd rather do things manually. ;)

@spongessuck yes but there are some system apis which are Swift exclusive.

@Lensflare thanks for the input. IMO a programming language that requires human to be "careful" in an area that the defects are very difficult to be spotted is not a good programming language, no matter how good the performance is. You know what it reminds me? It reminds me Internet Explorer <= 7 if you still remember the name. Back in the time it was using ARC and it was notoriously famous for it's leaking issue caused by closure having a reference to a dom in parent scope and that dom's onXXXX somehow referenced back to the closure.

@spongessuck thanks for the advice, i'd rather abandon the whole apple ship completely and code in kotlin/java with tracing GC happily forever.

@normanzb I partly agree in that a programming language shouldn’t require the dev to be careful.
However, it is actually very easy to avoid the mistakes in Swift.
99% it is in a closure and you can just blindly apply the weak pattern, which is just a bit of extra syntax: [weak self]
The other 1% is probably two class instances referencing each other.
And that’s not hard to avoid either.
Every time that you have a "parent" reference in some class relation, it should be weak.
That’s it.

@Lensflare sorry if you look into the IE case, it is actually object referenced closure that referenced upper scope variable that referenced back to the object. the chain sometime can goes very long.