Not sure what you're on about with the "overrelease" bit, but all ARC did was automate things with additional compiler support that were already automated.
And it caused additional crashes in code that shouldn't even be able to crash:
And although there is now partial ARC support for that scenario, partial is the keyword here, as it needs to obey specific access patterns to actually work.
But why on earth would I heap-allocate structs in Objective-C? That's what I have objects for. If I am going to dumb things down to structs, the reason is that I don't want heap allocation.
Unless I have no clue whatsoever as to what I am doing.
As in, I just wrote pure C (no Objective- at all) and for some reason changed the extension of the file to .m
Anyway, not using the solution that is there is not the same as the solution not existing, it certainly doesn't qualify as "the rest".
You "mpweiher" might not do it, but I assure you plenty of enterprise programming cogs do.
They code mostly in a C like way, and only use Objective-C at the level it is required to call into Apple specific APIs.
When using C++, then their code looks like what I call C+.
The same set of people that are to blame for Objective-C conservative GC never working in practice, when mixing Frameworks compiled with different modes.
I mean, sure, I believe you that you've seen this. But I've looked at quite a number of iOS/macOS projects and this was never a problem. Not even close. If anything, people were extremely hesitant if not actually afraid of using C features outside of the very basic ones like control structures, arithmetic and assignment.
Doesn't change the fact ARC doesn't work with structs, and people actually allocate them on the heap, hence why on 2018 Objective-C got some support for also applying ARC to structs.
Maybe time to also review the WWDC session and the points made there?
