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

[Ivan Vučica]

Look, I'm saying these things as someone that wants free software to
succeed, and I wish I could write more of it.

I also want GCC to be usable in the core.

However, not using a better runtime than GCC's and not using an
ARC-enabled compiler has costs for free software.

On Sun, Nov 24, 2019 at 1:24 AM Yavor Doganov <yavor@gnu.org> wrote:
>
> Developers who want to start using these new (not so new -- 10 years
> old!) features have the option to build the environment they need on
> top of Debian (if that is their distro of choice) or switch to another
> distro that provides prebuilt packages.

Debian and Ubuntu and derivatives are distros of choice for a large
number of users, incl. developers. Developers go ahead and just apt
install the libraries. Aside from UI concerns, they may or may not be
surprised to see a lack of language features they are used to on Mac,
used in sample code etc.

> You, developers, tend to forget that free software is for users.
> Developers are users too in a broad sense but they are a very small
> part of the whole mass of people using a particular piece of software.
> If these fancy features existed for 10 years, why they have not
> inclined developers to write more free software that is relying on
> them?  Surely that's not because Debian stopped them?  Or because the
> GNUstep project is stopping them?

Honestly, the things I lack to write an app:

1. various APIs
2. good autocomplete
3. better interface builder

All fixable in GNUstep without touching the compiler, and either way,
for me, all ignorable.

Now, let's say I start writing a fancy new app conforming to
best-practices way for people still using Objective-C with Cocoa.
Perhaps I'm starting on Debian with intention to support the package
to be built for Debian, and using lowest-common-denominator when it
comes to APIs.

I discover that even the lowest-common-denominator API-wise means I
have to avoid a bunch of language features.

Yknow what I do then? I don't necessarily go and build from source, I
drop the platform.

> My task as a free software contributor (with the extremely limited
> skills I have) is to help achieve the goals of the Free Software
> Movement.  Providing "tons and tons of features" to developers who
> don't care at all about free software (at least the majority of them)
> and who won't write a single line of code for the cause I'm aligned to
> doesn't strike me as the "right" thing to do.

I think you're conflating 'people who want to use new language
features' with 'people who develop proprietary software'.

I assure you that people who want to develop proprietary software
using GNUstep on Debian are well capable of doing that, including
using new features -- and they don't need to use prepackaged binaries
:)

People who want to discover GNUstep using Debian and want to use new
language features in free software might drop it instead of figuring
out how to build it from source. I mean, when I started off, I just
wanted to port my (never finished) free-software outliner (a tool to
edit OPML files). I was not interested in learning how to build
GNUstep or studying how the core works. I worked around
NSWindowController (or was it NSViewController?) missing in GNUstep,
and after complaining on the mailing list, I was told it was already
in the core, and I didn't have it because Debian packages were out of
date.

It took me quite a bit of time to bite the bullet and try to build
things -- because I trust Debian and want to, systemwide, install
minimum amount of non-packaged software that I can. Also, targeting
Debian was important to me, and writing something that was
unpackagable was something I didn't want to do. I never got any of my
own software into packagable state, though I was sometimes close.

> I don't mind helping them as a side effect of helping free software.
> In this case, however, it is all about them.

No, I don't think switching compilers to enable ARC for new developers
is helping only proprietary software :-)

>
> > - ARC is one.
> > - Blocks is another.
> > - @123 syntax for NSNumber (and similar stuff for arrays and dicts and
> > more) is another.
> > - Improved @property support is yet another.
>
> This is like offering rocket fuel to someone who has a car with a
> diesel engine.  None of the packages in Debian is using these
> features, which is why I said there's nothing to win.  There's a queue
> of software packages we intend to package in Debian but neither of
> them depends on these things -- except probably the Rik theme and
> NEXTSPACE (which are not suitable for packaging for other reasons).

Catch 22. You're describing a catch 22.

Even if I wanted to use ARC, I would choose not to, because I want it
to be usable with Debian. And you're telling me that libobjc2 and
clang are a no go.

But I am actually the weird one here: new Objective-C developers --
and I don't know if we'll get more of them in the free software world
given how Objective-C is treated on the proprietary platform, and
given the language features and API gap -- will want to use ARC.

Just because existing things don't use it doesn't mean people wouldn't
use it, if they could.

Are you recommending that I start using Clang- and libobjc2-dependent
features in my own code to effect change in Debian?

> Right now I'm working on a new upstream release of a package which
> uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
> This is a method which is declared and supposed to be supported even
> with GCC, I just don't know the (GCC) syntax I'm supposed to use so
> I'm experimenting with GCC nested functions as replacement.  If that
> fails, I guess I'll solve it somehow, using a different approach.
> That's the first case I face ever -- I've seen methods using blocks in
> upstream code before but they were no-op anyway as there was no
> GNUstep implementation.  On the contrary, there are tons of
> block-unrelated things which are not implemented, especially in GUI.

I'm not sure how it can work with GCC given that its last argument is a block.

========

$ cat tmp.m
@interface A
-(void)test:(void(^)())block;
@end

$ gcc tmp.m -c -o tmp.o
tmp.m:2:19: error: expected ‘)’ before ‘^’ token
 -(void)test:(void(^)())block;
                   ^
tmp.m:2:21: error: expected ‘)’ before ‘(’ token
 -(void)test:(void(^)())block;
                     ^

$ gcc --version
gcc (Debian 6.4.0-9) 6.4.0 20171026
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

========

Wikipedia claims:
"Apple has implemented blocks both in their own branch of the GNU
Compiler Collection[1] and in the upstream Clang LLVM compiler front
end"

Have blocks been merged after GCC 6.4.0? I'm installing latest GCC 9.x
from Debian unstable now to try this out. If I break my system, it's
your fault :-)

> The biggest hurdle with porting apps IMVHO is missing functionality
> and dependency on Core* stuff and other libraries with no free
> implementation.  The switch to Clang is not going to solve these
> problems.  The only thing it solves is making the life of developers
> of properiatary software easy.  That is not my goal.

How does allowing things like ARC make lives of ONLY proprietary
software developers easier?

> I don't know why Debian is important,

It's basis for numerous popular 'user-friendly' derivatives. (I think
it's plenty user friendly on its own, but *shrug*.)

You also happen to be one of the rare packagers that's interacting
with us here, so that's a bonus :-)

> but they cannot be made
> available as an option.  It would mean duplicate packages with
> different names -- the release team will not allow it and the
> ftpmasters will not allow it.
>
> You probably weren't around when we (GNUstep people in Debian) had to
> scrap and fight to prevent it from being removed.  GNUstep in Debian
> back then was undermaintained and violated the FHS, it was also full
> of bugs (that is, obvious bugs such as frequent failures to build from
> source) and blatant bugs solely due to packaging.  Hubert wrote a tool
> to FHS-ify most of the packages, we fixed most bugs

As a Debian user, but someone very clumsy when it comes to packaging
for Debian, I am greatly thankful for these efforts.

> and we had a
> helping hand from the Debian GCC maintainers who said it would be very
> worthwile to keep GNUstep in Debian, at least as a testing ground for
> GCC.

Alright, so that sounds like a major reason: binary packages are built
for GCC maintainers, not for app developers :-)

> And that's what it's been, more or less; GNUstep had a rapid decline
> in the user base some years ago and it appears it is not going to
> recover.  All the Clangs in the world are not going to help you with
> that.  But in your quest for popularity you may lose some of the solid
> foundations that are still keeping this project afloat.

I'm not questing for GNUstep popularity myself; if I did, I'd rather
sit down and try to finish the work on Core Animation being a possible
intermediary for blitting widgets on the screen. I'd work on creating
the 'gnustep-recommended-config' tarball which you could ship in
Debian as a Recommends:, including a specially tweaked session that
pulls in either WindowMaker+GWorkspace, or some other well integrated
combination.

Maybe a compositing window manager that understands NSDocument.

Or a DbusMenu server app that would paint a global menu using the
GNUstep widgets.

Y'know, the things that I love about certain other platforms.

In this case, it's about 'why can't we have these nice features out of
the box?'. I think we should have the nice features out of the box,
even if I think GNUstep core should not depend on them.

>
> > What's lost is builds on some architectures. Can't those architectures
> > keep using GCC-targeting libraries or be actively disabled?
>
> No.  Packages which no longer build for a particular architecture must
> be removed manually by the ftpmasters, after a request is filed.  If
> the architecture is official (meaning it is officially supported in
> the stable version of the distro about to be released) it must be
> decided by the release team.

This is really sad.

How would it be handled if core actually switched to *requiring*
clang? Would it be dropped out of Debian as something
infeasible-to-maintain?

> In case it still isn't clear -- I repeat, there is no middle ground to
> support both compilers/runtimes.

This is also really sad and holding the users of libgnustep*-dev back.