[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Chisnall
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Tue, 19 Nov 2019 13:19:48 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]