Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 19/11/2019 23:28, Ivan Vučica wrote:
> On Tue, Nov 19, 2019 at 5:26 PM Jordan Schidlowsky 
> <jordan@noodlecake.com <mailto:jordan@noodlecake.com>> wrote:
>  > Is this not the strongest argument to deprecate GCC, and just build 
> on Clang/LLVM?  If feature parity with Apple's API is the goal, isn't 
> this kind of a requirement at this point?
>  >
>  > There's other rather large projects moving purely to a llvm toolchain 
> (android ndk), so it wouldn't be totally unheard of.  They've deprecated 
> gcc and are removing it entirely in a future release.
>
> Multiple compilers is still a good thing (even if one of them is worse 
> than the others).

I agree in theory, but in effect the two compilers support entirely 
different languages.  The jump from the dialect of Objective-C that gcc 
supports to the dialect that Clang supports is similar in terms of user 
experience to the jump from C++98 to C++11.  All of the C++ projects 
that I work on have now switched (or are in the process of switching) to 
depending on C++17, because it's a significant productivity boost.

Supporting GCC is not free.  It adds cost to every single GNUstep 
commit.  You have to think about memory management, not just simple 
ownership rules.  You have to use macros instead of core language 
features (such as fast enumeration).  You can't use weak pointers.  You 
can't use blocks.

If GNUstep had a large army of developers, I'd have no objections to 
this.  At the moment, GNUstep is severely under-resourced and time spent 
supporting GCC is time not spent getting the core libraries up to parity 
with a vaguely recent version of macOS.

> GCC users can accept that not all applications will be compatible, if we 
> can't implement APIs that depend on the "new" features.

Again, GCC users are not the only ones that are paying the cost.  I did 
a run with the ARC migration tool a while ago and around 2/3 of the 
GNUstep source files could be automatically migrated, many of the 
remainder needed only minor tweaks.  Using modern Objective-C++ in the 
core of GNUstep could significantly improve productivity.  For example, 
GSIMap is an implementation of a hash table using C macros.  It is very 
difficult to modify (I think I have broken something every time that 
I've tried).  Replacing this with a C++ template would be fairly simple 
and would make it much easier to switch to other implementations as 
required (there are a bunch of well-optimised C++ hash table 
implementations with compatible interfaces tailored to different uses, 
we could just pull half a dozen of them into the codebase and use them, 
complete with type safety rather than a load of casts through void*) 
Oh, and with ARC, all of the C++ implementations have correct memory 
management for Objective-C, for free.

> But perhaps dropping GCC fully is too drastic.
>
> I have a similar opinion about some GUI backends; they're not very 
> useful, but guide gnustep-gui and gnustep-back APIs to be more flexible 
> and don't depend on just e.g. Cairo.

Again, this comes at a cost.  For a long time (I'm not sure if this is 
fixed now), Cairo was slow and flickery because it was being forced to 
go via a double-buffering mechanism that was designed for libart. 
Removing this without breaking the xlib and art back ends was nontrivial.

Even today, I believe the Cairo back end is still using the 'toy' font 
APIs and not the ones that integrate with Harfbuzz, so we get quite poor 
kerning with Cairo and miss some important features.

David