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

[David Chisnall]

On 18/11/2019 11:31, Gregory Casamento wrote:
> Currently I know about the following missing functionality:
>
> * ARC

These three letters hide a huge amount.  It isn't just inserting 
-retain/-release calls, the requirements for ARC are:

 - Add the concept of method families for controlling ownership.
 - Add syntax for the qualifiers and attributes for overriding 
autodetected method families.
 - Add a set of lifetime analyses in the front end to detect where to 
insert the ARC calls.  There are around 20 different calls inserted here 
depending on the analyses.
 - Add some non-trivial optimisations to elide most of the refcount 
manipulations (without these, ARC code has a lot of redundant refcount 
manipulation).
 - Support ownership metadata in the ivar reflection info so that the 
runtime can properly implement object_setIVar().

In Clang, this is about as much code (scattered throughout the codebase, 
interacting with other aspects of C and C++ language semantics in 
non-trivial ways, with a high testing overhead) as the entire 
Objective-C implementation in GCC.  The complexity of adding this to GCC 
is greater the complexity of adding Objective-C support to GCC from 
scratch was.

> * block support

The Apple fork did have blocks support, but it was the old ABI and broke 
in exciting ways.  Blocks in modern Objective-C have some non-trivial 
interactions with ARC.

> * template support (for collection objects like NSArray<NSString *>)

Note that these are not templates, they are type-erasing generics.  I 
believe GCC's Objective-C++ support is sufficient that you can use 
Objective-C classes as template parameters (which means you can 
implement smart pointers that wrap Objective-C objects, which gets you 
about half way to ARC in terms of usability).

Generics would probably be relatively easy to add, because they're just 
semantic analysis: they're gone by the time code generation occurs.

> What else is currently missing?  

Apple stopped using Objective-C 2.0 over 10 years ago, so it's probably 
time that we stopped doing so as well.  There are a bunch of features 
that are a mix of language and runtime things and sometimes difficult to 
deconflate.  Here's a rough list of things that I know are missing on 
the language side:

 - GCC supports declared properties, but none of the newer modes (e.g. 
weak).
 - GCC does not support property introspection metadata.
 - GCC does not support class properties (I'm fairly convinced that 
these are a bad idea, so that's not a huge point against it).
 - GCC does not support the non-fragile ABI and so can't support ivars 
declared in an @implementation context or a class extension.
 - Objective-C literals.  Clang supports number, array, and dictionary 
literals.  I am in two minds about whether this is a good idea.  I don't 
like the clutter in the language, but I do find that they are very 
useful in practice.
 - Subscripting for collection classes.

GCC has, I believe, recently gained support for instancetype.  I think 
it also supports fast enumeration, but I'm not 100% sure (in 
Objective-C++, you can quite easily wrap NSFastEnumeration in a C++ 
iterator, so you can work around this and GNUstep has macros for using it).

There's also the new ABI, which provides a bunch of things that are not 
directly surfaced in the language, but which depend on compiler support, 
such as:

 - Using objc_msgSend on platforms where the runtime supports it (this 
has knock-on effects on some of the forwarding).
 - Selectors are deduplicated by the linker.
 - Protocols are deduplicated by the linker.
 - Constant strings contain a hash.
 - GSTinyString for 8-character ASCII strings on 64-bit platforms.
 - Richer ivar metadata (size, alignment, ARC ownership).
 - Methods have extended type info, allowing the JavaScriptCore bridge 
to work.
 - SEH-compatible exceptions on Windows.

These changes don't require modifying any of GCC other than the codegen 
layer.

> Is anyone interested in helping to implement these features in gcc?

Iain Sandoe was interested in getting GCC to feature parity, but I don't 
think he's made much progress and I don't really see the value in 
sinking 2-3 developer years of work into a project to get GCC to support 
a language that the GCC developers don't care about and where the demand 
among users for a GCC implementation is negligible.

If someone has budget to employ a developer for 2-3 years to work on 
something to improve GNUstep, I can think of a few hundred things that 
would have a higher impact than adding modern Objective-C support to GCC.

David