for e.g. Rust does not have GC nor ARC as built-in in Rust programs, and Rust uses RAII.
As i understand Rust implements RAII via ownership, borrowing, lifetimes, and Rust has borrow checker built-in in Rust compiler.
So, no built-in GC, no built-in ARC in Rust.
It seems we are talking past each other. RAII is not a memory-management technique. RAII does not replace GC, ARC, nor manual memory management (such as ObjC's retain/release or C++'s delete).
(You can use RAII to manage manually-allocated memory, but you still need a mechanism to manage the memory used by the object which is implementing the RAII pattern.)
FWIW, an apt comparison would be Rust's [ownership, borrowing, lifetimes] vs Swift's [ARC]. You can already use RAII via Swift's ARC, as much as you can do RAII via Rust's ownership/borrowing/lifetime.
I don't think that is a fair accusation. I admit it is not quite clear from this thread alone, but if you read the documentation of Rusts Arc/Rc types linked above, you'd know that these types allocate and deallocate the memory for you, and use something that can reasonably be described as RAII, as each instance of the Arc struct effectively translates to a +1 to the reference count keeping the underlying memory alive, owned by the code holding ownership of the Arc instance.
Once all instances pointing to a region of memory are dropped (e.g. all those +1s are removed), the memory managed by that set of Arcs is deallocated. In effect, it's opt-in automatic-ish reference counting, implemented entirely in the Rust stdlib, instead of being baked into the compiler.
I already laid out that I don't think it's a good fit for Swift, which takes the approach of by default doing the thing that works well 95% of the time, rather than Rusts approach of making every memory management choice very clear to the user. But it is in fact a model that uses RAII concepts for memory management, and could perhaps have niche use-cases even in Swift (having reference counted single instances of large structs maybe? although that need would probably be served just as well by wrapping it in a generic class), and will probably be implementable in any old Swift library, once the necessary features make it into the language.
I'm not at all familiar with Rust, but something has to be managing these Arc instances. Unless it's RAII all the way down, Rust has some mechanism that isn't RAII for managing memory.
I already wrote above that you could use RAII to manage manually-allocated memory in Swift. It can be treated as a resource, just like file handles or network sockets. But you still need a mechanism to manage the resource manager.
Effectively, it has malloc and free (although not exposed as such).
References are structs, and their lifetimes control the reference count of a box. This is largely analogous to how shared_ptr works in C++, the quintessential example of memory management through RAII (treating references as resources, not memory).
In order to implement something similar in Swift, you would need deinits on structs and either move-only structs (as in Rust) or copy constructors (as in C++).
I figured it must be something like this. There is a system upon which other objects can have their memory managed by RAII techniques. At the end of the day, whatever Swift may get (struct deinit or copy constructors) to allow the same techniques to be used, we'd still have ARC (and its equivalent for structs) underlying the memory management system.
In all honesty, it's still plausible to have an opt-in Rust-style lifetime management for limited scope. But that's probably not what this thread is about.
Aside from reducing the small Objc/Swift fragmentation, nothing really. And Iβm not the one that needs convincing, given how well the interop works, I think itβs fine either way.
I mean that if Swift were to change to use an explicit Arc type, I would have to write it all over the place in my apps, given the extent to which they interact with ObjC APIs. The more modern Swift code would be less of a problem, I think, because it's more value oriented.