Hugo, As lead I need to preface this with the following... these are my OPINIONS not DECISIONS from my experience with the group. Also, I'm speaking only for myself...
On Sat, Aug 31, 2024 at 8:42 AM Hugo Melder <[email protected]> wrote: > 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. > The question about which compiler we should use as a minimum is always a balancing act between supporting older architectures and newer features. It comes down to maintainability. Anything that impacts our ability to improve and maintain the code is where the line need to be drawn. This is why 2.94 was abandoned. First, it was ancient when we abandoned it, but second it posed a maintainability problem since many macros needed it and since there are macros that use variables throughout the codebase (seems like a simple feature, but the older compiler didn't have it). So here we must ask ourselves the very same question. What is it about newer versions of GCC that make it easier for us to maintain the project and does keeping GCC4 as the minimum hurt us? > 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 ;) > > Well, here, I think we have a deeper question. The reluctance to use C++ in the codebase is one of simplicity. We didn't use C++ for a while because the handling of exceptions was incompatible. I know it is now when using clang, but I am not sure about the GCC side. So, it was deemed safer to do everything in C and ObjC and keep the mixing of C++ to a minimum. This is another question we need to address and that is whether we feel as though it is now acceptable to using C++/ObjC++ more in the codebase. > 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? > In a word. Nope. :) In general, GNUstep doesn't deprecate methods or classes. This allows a wider range of compatibility. The idea here is that unless it hurts us to keep it, we don't deprecate it. > 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 tend to agree with this, libdispatch is ubiquitous and very useful. We should use it where it's reasonable. NSOperationQueue seems a likely candidate, currently it is implemented using NSThread. Again, I think this is mostly about keeping things simple and reducing dependencies. > I would like to hear your opinion on this! Please remain on topic. > > ~ Hugo > Yours Sincerely, GC -- Gregory Casamento GNUstep Lead Developer / Black Lotus, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com https://www.patreon.com/bePatron?u=352392 - Become a Patron https://www.openhub.net/languages/objective_c https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation
