> ObjC had some elision tricks like objc_retainAutoreleasedReturnValue, but more importantly the optimizer was taught about RC manipulation.

Cough. Actually, before ARC the ownership rules really kept RC traffic very low, and you could drive it lower still if you knew a bit about how ownership worked in your code ("these will balance and the object is already owned elsewhere...").

ARC just went mad with trying to give guarantees it really had no business making, and then hoping the compiler would be able to remove them again (difficult with message sending).

This caused some amusing bugs, for example a crash in the following method:

   -someMethod:arg and:arg2
   {
       return 0;
   }

How could this possibly crash? All it could possibly do is clear register AX and return.

Well, with ARC enabled and in debug mode, it inserted code to first retain all the arguments, and then immediately release all the arguments. Apparently one of the args was a bogus pointer (framework-provided, so out of our control) and so it crashed.

So the result of your instructions that have undefined behavior turned out to be not what you wanted? That’s hardly a problem with the language.

Interesting that

    return 0 

is now considered "undefined behavior".

Whatever.

Obviously the problem is with using objects in the message which are invalid. The compiler may or may not work as you expect and that’s your problem, not the compilers.

You can try to defend yourself by stating the call is done by some framework but that just means the problem is still not in the language, it’s in the framework.

First, the compiler and framework come from the same vendor, so it's perfectly fine to blame them. Unless you consider things like compilers and frameworks to be independent subjects capable of being blamed.

Second, whether the behavior is defined or undefined, the compiler has no business touching arguments that the code didn't tell it to touch. If it does so, it isn't fit for purpose and can be criticised as being unfit for purpose.

And the C standard is very clear and adamant that being in compliance with the standard is not, and in many ways cannot be, equivalent to being fit for purpose.

Last not least, I think we are probably not going to agree as to whether dereferencing unused arguments is a valid response to the presence of undefined behavior. See

https://blog.metaobject.com/2018/07/a-one-word-change-to-c-s...

So efficient that Swift's RC implementation loses against all major tracing GC implementations.

https://github.com/ixy-languages/ixy-languages

That project doesn’t compare GC implementations, so it’s probably not that useful here.

Also, the Swift implementation is a bit questionable if performance is a goal. That is, why not try to remove the memory management from the inner loop? Probably the first thing to try is value types instead of reference types, which are more generally preferred anyway.

Sure it does, memory management impacts the performance of the task being achieved, writing an high-speed network driver.

By that measure, every project is a good measure of GC performance. Is that really a good argument?

I believe all general purpose languages let the code allocate memory and therefore will let you allocate memory in a way inefficient to your task.

The argument is that to eventually write Swift code whose performance matches the competition, one needs to work around ARC's implementation.

Hence why there is so much emphasis on value driven programming alongside protocols at WWDC talks.

My claim was about efficient COW collections and the FFI. The point of COW collections is enabling a simpler programming model.