Re: Automated Reference Counting (Was: Disappointed by GNUstep)

Richard Frith-Macdonald <[email protected]> Tue, 8 Feb 2022 12:40:06 +0000
Newsgroups gmane.comp.lib.gnustep.devel
Message-ID <[email protected]>

> On 8 Feb 2022, at 11:01, David Chisnall <[email protected]> wrote:

>   I could write significantly simpler code that ran faster using Objective-C++ and ARC than I could without either and GNUstep would not accept the less-buggy and faster option.  Refactoring code to make it less maintainable so that it could compile with an old compiler and spending time finding bugs that are impossible by construction with ARC felt like a complete waste of my time.

Well that could be a bit misleading: while GNUstep policy has not accepted breaking the portability of existing code it has never prohibited the addition of new non-portable features (though obviously portable is preferred).
GNUstep has always encouraged contributions, and new contributors often have specific areas of expertise allowing them to contribute valuable code, but lack the expertise to make that portable. 
This has mostly been a factor with the windows/unix divide, where we would welcome an implementation of a new class for one platform (and work on or hope to get a contribution of another implementation of the other later), but we have compiler-specific areas of code too.
There's a big difference between what is preferred (fully portable code for all features) and what is acceptable/unacceptable.   We are conservative about keeping existing code working on existing platforms, but very liberal about new functionality.

So the issue about moving to clang here is about a process/timescale for potentially refactoring existing core code in ways which would depend on clang.