Re: Should we split the project into two branches?

[Hugo Melder]

The mainline branch focuses on maintaining the highly portable codebase, while the Next branch focuses on features and library support, free to break compatibility with anything that is less than popular in the wild

There are multiple problems with your proposal that are obvious when working on a large codebase.

The GNUstep libraries are compiler independent and modular by nature: ABI differences like blocks, MRC vs. ARC, the @optional _expression_ in protocols (Not supported in early GCC versions) are all handled on a preprocessor level. The NSURLSession API uses GCD and the blocks runtime and is therefore only compiled when using the clang/libobjc2 toolchain. This conceptual difference is more flexible and resilient to macrostructural changes.

An upstream branch for “features” and “library support” will slow down the pace of development significantly when offsetting the additional work required to sync changes to the mainline branch.

[…] a major refactor to libobjc2, base and corebase, and maybe even a new ABI

Sure let’s create a new ABI…  This reminds me of a quote that I heard in an old BBC "Desert Island” record interviewing architect Richard Rogers. Rogers had an objection for people deeming themselves experts: “Everybody has an unsung architecture in their life, wether it’s changing a door or building a house. Everybody is involved and therefore everybody is a professional”. Richard Rogers planned the remarkably innovative Pompidou in Paris and Lloyd’s building in London. Both buildings were highly controversial but as it turned out just ahead of the time. Pompidou surpassed the Eiffel Tower in visitors and Lloyd’s building was the beginning of modular thinking in architecture (All utility and elevators are on the outside to be easily repaired or upgraded in the future). Modularity is not only a singularity in architecture but can be applied to development as well by having a solid toolchain-independent core and all facilities regarding toolchains separated.

Swift compatibility is likely going to end up requiring breaking changes.

No. There are the NS_SWIFT_NOTHROW, NS_NOESCAPE, NS_ASSUME_NONNULL_{BEGIN,END}  and a few more macros that are used to provide further information about exception handling etc. Objective-C interoperability requires no big changes to the FoundationKit and ApplicationKit. 

[…] we may even start incorporating Apple’s Apache-2.0 code in this project, taking bits and pieces from that open source release of Swift language. For example AFAIK there is an Objective-C runtime core in libswift that is both ObjC 2.0 compliant and very performant, which may even be a fork of the version of libobjc Apple used in macOS and iOS, maybe we can just nab that to make our libobjc2 more performant.

It is naïve to think runtimes and projects that implement the same high-level API share the same low-level structure and implementation details. I recommend the papers regarding the Etoile and libobjc2 runtimes by David Chisnall (https://queue.acm.org/detail.cfm?id=2331170, http://www.jot.fm/issues/issue_2009_01/article4.pdf).

P.S. Remember the quote