Re: Embedded blocks...

[Yavor Doganov]

В Tue, 29 Oct 2019 12:50:23 +0000, David Chisnall написа:
> On 27/10/2019 16:05, Gregory Casamento wrote:
>> We are a GNU / FSF project.  Dropping support for GCC would be bad
>> political mojo.   There is little we can do to bridge the gap other
>> than doing these macros.
> 
> I don't really understand how this works.  GCC does not support a
> post-2005 dialect of Objective-C.  GNUstep is a framework that aims to
> provide an implementation of the 2019 Objective-C standard library.  Why
> is it politically problematic for GNUstep to drop support for GCC, but
> not problematic for GCC to drop support for GNUstep?

But GCC didn't drop support for GNUstep.  It just cannot cope with the
changes of the language/runtime that are completely under the control
of a single corporation.  It is not surprising that the last major
changes in GCC related to Objective-C were implemented by GNUstep
developers (Nicola and Richard, IIRC).

> For what it's worth, I've spoken to a couple of GCC devs over the
> last few years about supporting modern Objective-C (because I would
> like us to have a choice of compilers), but the effort involved for
> them is huge (even a naive ARC implementation is a big piece of
> effort) and the return is small (why would anyone use it?

You are right that it's a monumental effort and that they probably
don't have the motivation.  The pool of free software written in
Objective-C is rather small and it doesn't tend to increase.

> Basically, the only target market is GNUstep developers on platforms
> that Clang doesn't support, which I think is a set containing only
> Riccardo).

This is an exaggeration.  I fixed a bug in SOPE on SuperH just a few
months ago.  Over the years, I recall fixes in GNUstep core libraries
on HP-PA, GNU/Hurd and GNU/kFreeBSD, to name a few.  And non-core
packages on sparc, ppc, ppc64, powerpcspe and m68k.  GNUstep aims for
portability and this is closely related with code quality.  Once you
start dropping targets for no good reason you can expect regressions
in quality here and there, and more effort when the need to support a
new architecture arises.

As it stands, none of the GNUstep reverse dependencies currently in
Debian will benefit if we suddenly switch to LLVM/Clang.  We'll just
have to stop building the GNUstep stack on about half of the
architectures and at the end it will reflect back on GNUstep.

В Wed, 30 Oct 2019 01:27:56 +0200, Sergii Stoian написа:
> IMHO political motifs shouldn’t constrain technical decisions

Well, the goal of the GNU Project is technical but that goal is set
because of an ideal and GNU maintainers are supposed to exercise
proper judgment when making decisions on technical matters, too.

> Moreover using these nice Objective-C 2.0 features make GNUstep code
> look much more familiar to potential macOS/iOS developers.

It is extremely naive to expect that macOS/iOS developers will start
coming in numbers, anxious to implement classes and missing
functionality, just because of that.  GNUstep predates the thing
called "Objective-C 2.0" and I don't remember an avalanche of patches
flowing in before 2005.

(Likewise, it was foolish to presume that the move to GitHub will
install an entire new generation of energetic programmers.  The
reality is that pretty much the same small set of heroic people are
doing the work.)