Hey, I’ve looked into the coding guidelines of libs-base and have not found a mention of a minimum supported compiler version. This means there are no real guarantees on the C language version and a memory model whatsoever. Starting with C11/C++11 we converged to SC-DRF and now have built-in atomic operations and overall better guarantees due to codification of a memory model.
This would avoid doing UB such as using plain ints for gsrefcount_t without even issuing a warning (https://github.com/gnustep/libs-base/blob/7474bd80e3f4611ad52a2b76e85d39f60ea956dd/Source/NSObject.m#L385). There are other instances of workarounds and hacks for archaic GCC versions. Platform-dependent atomic operations for object reference counting is currently implemented in inline assembly. We should remove the responsibility of generating correct instructions to the compiler and use the C11/C++11 atomics instead. My proposal is to bump the minimum supported GCC version to GCC 9.x which is the supported version in RHEL8. When enforcing this minimum version of GCC, we can focus on writing C17 (GCC 8.x or later). For the libobjc2-based toolchain, any recent clang version (16 or later) will do. Background for this is that older clang versions had serious bugs when targeting MSVC. Using C++ in the Codebase I am aware that this is a disruptive proposal but I’d really like to see modern C++ in our codebase. Compared to the more conservative C STL, the C++ STL is fast and really feature rich. Just take a look at std::transform, std::reduce, for potentially parallel operations, or the wrapped pointer objects. It is generally safer to use RAII then to juggle with bare new and deletes (or mallocs if you will). We can also utilise some templating to reduce the boilerplate in KVO and other instances when we need to parameterise a function (KVO because of the type encoding cases). Who needs Objective-C blocks if we have lambda functions ;) As we are only exporting ObjC, this would not impact ABI stability. Proper API Deprecation Policy Apple deprecated a lot of functions and classes in recent years. Are we going to do the same? Should we remove them after at least two major GNUstep releases? Make Grand Central Dispatch a first Citizen Libdispatch is really great. Apple spent a lot of time and money refactoring their internal codebase to use libdispatch instead of lower level pthreads or NSThreads. We should do the same and make libdispatch mandatory for the Foundation library. This will result in more efficient resource usage and a better concurrency “model” than what we have now. You can compile libdispatch without block support and use it with GCC. The only problem is the absence of a libdispatch package in the Debian and Ubuntu repositories. I would like to hear your opinion on this! Please remain on topic. ~ Hugo
