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

[Fred Kiefer]

> Am 22.11.2019 um 15:44 schrieb Andreas Fink <afink@list.fink.org>:
> 
> The fact is that gcc can not do ARC. This is the main show stopper for gcc. 
> On the other hand, switching from gcc to clang is not a problem for 
> "traditional programming style" programmers.
> 
> The only problem I can see is platforms which gcc supports but clang does 
> not. So the real question is are there any users who use ObjC stuff with 
> GnuStep under, lets say strange embedded systems.
> Given ObjC does not have a bright future under gcc anyway (as they have still 
> not implemented ObjC 2.0 features after like 10 years it's out now), does 
> mean it will only get worse.
> 
> Besides that we have to consider that sticking to gcc will also hinders 
> newcomers to get involved. And this i I think is a important point.
> The developers hehre with 20 years+ experience will have no problem working 
> around non ARC stuff and going backwords because we all know the  old way.
> The youngsters out there however don't. If we want to get Gnustep into the 
> modern area, we will need to be attractive to newcomes and this means keeping 
> up with the modern API's etc. And gcc is miserably failing here. Thats the 
> main problem, not if you don't want to use ARC (which is still fine) or not. 
> Others want to use ARC but can't under GCC.
> 
> In other words, going for clang doesnt mean ObjC 1.0 code wont run but it 
> means a lot of ObjC2.0 code will start to run.

This is another discussion I would have preferred to stay out of. We had this 
and other similar discussions so many times before. To me it just seems not 
worthwhile to participate once more.

There are many benefits that ObjC 2.0 support with clang could bring, still I 
can understand why some people prefer to stay with a compiler and a language 
they know. I myself use gcc and even with its limitations it allows me to do 
useful programming for GNUstep. And many times gcc has pointed to bugs in the 
code where clang accepted the code. (The opposite is also true, it really has 
been good for us to have two different compilers to inspect our code.) What I 
would never do is to argue for others to use gcc. Just use the compiler you 
prefer.

And this is where this discussion is getting odd. It has been possible to use 
GNUstep code in ObjC 2.0 projects, thanks to the great work David has been 
doing. And if we are honest the work to support this inside of GNUstep wasn’t 
much. Just using a few macros here and there and things work. We could even go 
further and have a few more macros that allow us to specify the property 
attributes in GNUstep base and redefine the ASSIGN, RETAIN and RELEASE etc 
macros as noops and with a bit of code cleanup GNUstep base could be compiled 
with ARC. All of this should be possible while still keeping support for gcc. 
Even for simple block usage I am sure that if David and I set down for a 
weekend we could come up with a macro to define a callable block (probably 
without capturing variables and without ARC special cases, just the most common 
case). It is just that the need for this hasn’t come up.

I really don’t see gcc support is itself holding us back. At least not more 
than the incomplete CoreFoundation, or the fact that base is not build on top 
of core base, the binary incompatible of Foundation and GNUstep base or the 
missing usage of C++ in the implementation of GNUstep. These and some other 
factors seem more important to me. But if we start to change all of these, the 
resulting project would be quite different from current GNUstep. And most 
likely we would have lost most of the current GNUstep developers in the 
transition process. Nobody can tell whether we would gain new active core 
developers through this change. I really doubt that and therefor would prefer 
not to drop gcc support. If you disagree, fine. But for GNUstep it would be 
great if you could pledge to work on the code in the next few years. Otherwise 
the project will be dying even faster than it is now.

Fred