-fnext-runtime vs. -fgnu-runtime smackdown, #7, conclusion

Like all good ties, this smackdown tie will have people arguing for a long time, who really won, who is better? Everyone is silently thinking "I want to be on the winning side"

There are no winners here. Due to how gcc is partitioned into -fnext-runtime and -fgnu-runtime, the GNU runtime is losing out on work that Apple is doing for Objective-C, and if someone other than Apple wants to use -fnext-runtime they need to do a lot of work to get their runtime going. If the differences between the runtime interfaces could be straightened out, there would be a lot less duplicative effort being made and hosting Objective-C on a given platform would not be as much work.

The GNU runtime interface started out being just a different function interface to the same data structures. Over time, people used the -fgnu-runtime flag as an excuse to neglect the data structures in libobjc or to bastardize the existing ones in the name of experimentation.

I say get rid of -fgnu-runtime, make the function interface the default. But keep libobjc up to date on the data structures, and for the love of all things good, get rid of typed selectors, they are terrible. NeXT's and Apple's performance oriented dispatch functions can be turned on if desired. Some enterprising people could update libobjc to support the NeXT dispatching if desired, and the new performance oriented ones that Apple has been adding. It would benefit everyone.

Summary

- Get rid of typed selectors
- Unify the data structures used in both runtimes, follow NeXT's/Apple's lead here
- Use the current -fgnu-runtime function interface as the default

Add two compiler flags:

-fobjc-enable-msgsend this would generate NeXT style dispatch calls
-fobjc-period-symbols this would generate NeXT style object code symbols with the period in them.

This would bring the original spirit of -fgnu-runtime interface back and make it the default. The performance oriented, but not so portable, NeXT and Apple changes can be integrated into libobjc if desired. Everyone out there using Objective-C somewhere other than Mac OS X could benefit from these changes and it would streamline the Objective-C support in gcc.