Is it possible to replace ARC with RAII in swift?
And move ARC from compiler to stdlib(create struct ARC).
They are for different purpose, right? RAII means you tie resource ownership to an instance lifetime. ARC helps you manage instances lifetime. If anything RAII would be using ARC (not that we move it around). Or am I missing something?
1 Like
It would break pretty-much all Swift code in existence, so I’d say it’s unlikely.
1 Like
i suspect code breaking would mean that code was erroneous
i thought ARC, GC, RAII were about memory management?
Not if the language changes in such a way where it’s no longer automatically retaining/releasing class instances as you pass them around. Suddenly you’re back to manual memory management, but you haven’t written any code to do that.
ARC and GC are, but RAII is resource management (using memory management). Unless you’re applying it in a way that I didn’t think of, or that you mean something other than Resource Acquisition Is Initialization. In fact, things like FileHandle would qualify as RAII.
1 Like
Well, it wouldn't be that far fetched to look at a strong reference to an object as a resource, and then have a struct that retains a class instance passed to it's initializer, and releases it when the struct is destroyed. For that to be possible and not prohibitively difficult to use, we'd need at least copy constructors/move-only types and struct deinits. Possibly some form of automatic wrapping as well, to tone down the verbosity a tad.
I don't think—even ignoring source compatibility—this would really be worth it though. ARC does a pretty good job overall. If you need better performance, Unmanaged is probably a better tool than an ARC<T> struct, which would be more of a side-step performance-wise, might prohibit optimizations the compiler can apply to ARC, and would require you to wrap many parameters and variables in ARCs, which would probably get pretty verbose.
But but, who's gonna manage Arc<T>? Who's gonna police the police?
maybe those who use Arc<T> in their codebase?
compared to what?
So we elevate ARC into a special struct/class. Hmm, I guess that’s a valid memory model, though now we need to deal with leaking ARC. I’m not sure it’s any better than ARC. I’d prefer that programmers don’t have to deal with memory management too much, we’re never good about it.
Also, if we nudge it a little bit, we'd get pretty close to Rust's memory model. Which is something Swift might be able to use.
1 Like
in Rust Arc is just struct in stdlib, not in rustc.
btw, Rust uses RAII, not ARC.
You mean Atomically Reference Counted in Rust? That's different from Automatic Reference Counting in Swift. Well, they're both reference counting, so I guess.
IIRC Rust uses ownership model for memory management, and fallback to reference counting where appropriate.
RAII is just a pattern that utilize these memory management.
4 Likes
I think this discussion is lacking a clear definition of a problem to solve.
@asdf Do you have examples of what you want to achieve through RAII to better orient the discussion?
5 Likes
Excuse me, but this doesn‘t seem like a heated discussion so what‘s the point of flagging the original post? Regardless of the trivial answer to the original question it is unfair to flag the post. @forum_admins can you please revert that? Thank you.
11 Likes
Yeah, I was going to ask the same question. I don't see any applicable rationale for flagging under the flag options.
Was confused about the flagging, too. Wondered if it got toxic later on, it didn't. Should be reverted.
But what is the mechanism? ARC is what causes objects to be deallocated when there are no strong references remaining. If ARC is just a stdlib type, what causes anything to ever deallocate? Are you suggesting that they be manually managed?
Apple's ARC (used on objc and Swift) is completely orthogonal to RAII. They serve different purposes and solve different problems. One cannot replace the other.
1 Like