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

[Fred Kiefer]

> Am 26.11.2019 um 22:18 schrieb Stefan Bidigaray <stefanbidi@gmail.com>:
> On Tue, Nov 26, 2019 at 12:17 PM Gregory Casamento <greg.casamento@gmail.com> 
> wrote:
> > One more questions... what do the GCC Objective-C maintainers have to say
>> >> about this discussion? It would seem that GNUstep is now their only
>> >> downstream "customer". Are they open to working with us to provide a more
>> >> compatible compiler?
>> >>
>> >
>> > They haven't seen this discussion.  They would likely expect us to make
>> > these changes ourselves and, as David Chisnall pointed out... there is
>> > about 2 man years of work there.
>> 
>> I completely understand that part. My suggestion was to How long would it
>> take to implement all the language features, except ARC and blocks, in GCC?
>> Could we implement the non-fragile ABI, @properties, generics, etc. in a
>> reasonable amount of time? How hard to replace the GCC-runtime with the
>> GNUstep-runtime? If this is more palatable, then is it a worthwhile avenue
>> to pursue?
>> 
>> My suggestion is, essentially, to get GCC to a more compatible position.

If I understand you correctly your suggestion is that we try to add support in 
gcc for some of the basic ObjC 2.0 features. That should be doable although the 
last time I tried I gave up on it. That was right after the Dublin meeting 
where we had a similar discussion to this one. The gcc people at that time 
where open to accept patches, but we should not expect too much help coming 
from their side. The reason I gave up was that at least a new version of the 
meta information that the compiler creates for the ObjC meta information was 
needed and I could not figure out a place where to flag that difference.

>> > At the end of the day, GNUstep has been around for a very long time, and
>> >> like it or not, backward-compatibility is important. I personally believe,
>> >> based on some of the discussion here, completely dropping GCC is going to
>> >> be cause more problems than it solves. Whatever the decision, the
>> >> implementation should be well planned and deliberate.
>> >>
>> >
>> > I'm not so convinced.   GCC does nothing, but slow us down.
>> >
>> 
>> That could be said about all backward-compatibility. A follow up question
>> is, does it hold us back enough to justify breaking compatibility? It seems
>> some people think yes, and others think no. We're at a stalemate, where no
>> progress can be expected to take place. For things to move forward, either
>> one side has to give in, or both sides can compromise and agree to a middle
>> ground.

You described the dilemma very well. (And I also want to thank David and Ivan 
to their excellent contributions to this thread.) Some people are very 
conservative in this group. But others have a bit too much wishful thinking. I 
myself would not mind too much loosing gcc but loosing active developers and 
packagers. Sadly for some this doesn’t seem to be an argument.