I forgot... "What's to gain" should also contain:
* Simplification of the code. We will not have to use any #define macros in order to bridge the gap between what are, essentially, two different languages. * C++, while this is not exclusive to clang, gcc doesn't support the latest version of C++. Clang is extraordinarily good at optimization. * Performance, Since clang optimizes so well, we could replace some critical things which are currently written in C with better versions written in C++. David already mentioned GSIMap. There are others. So, yeah... I am not sure what else, but there might be more. Yours, GC On Mon, Nov 25, 2019 at 4:30 AM Gregory Casamento <greg.casame...@gmail.com> wrote: > Yavor, > > > On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov <ya...@gnu.org> wrote: > >> [ Posting this via NNTP, hope it works. ] >> >> Ivan Vučica wrote: >> > Distro packagers should also voice their opinion on whether they can >> > switch to Clang (and, hopefully, libobjc2), which I'd invite them to >> > do no matter what the decision is on presence of Clang-dependent >> > code in GNUstep core libs. >> >> I guess distro packagers who prefer Clang (or have no reasonable >> choice as that is the default and perhaps the only compiler on their >> distro) have made their choice already. >> >> Regarding Debian, I would like to point out that I cannot speak for >> them. I am neither a Debian Developer nor a Debian Maintainer. I >> also cannot speak for the Debian GNUstep team as I don't hold any >> special position there. >> >> But I'll have to repeat what I've said several times to fellow team >> members and other people asking me the question "Why Debian's GNUstep >> doesn't switch to Clang?". The answer is simple: because there's a >> lot to lose and nothing to gain. >> > > This is patently incorrect. The gain is time and compatibility with the > latest code base. I laid out the advantages and disadvantages of this in > my previous posting. I entail you to look that post up, but I will put > what I think the losses and the gains are here for your convenience: > > Switching to clang... > What's to gain: > * Time, time spent doing things the compiler can do automatically is a > waste of time and, more importantly, time NOT spent on fixing or working on > the CORE problems. > * Compatibility, much of the API is moving towards using blocks. Blocks > *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near > future. > * Developers, gaining developer interest means more applications. > Supporting an up to date version of the language which is in line with > developer expectations helps to attract them. > * More Applications, more applications means more end users (sort of > chicken and egg thing) > * Swift, Possibility of integration with open source swift. With GCC this > is not possible. > > What's to lose: > * Possibly a political issue with the FSF, but there are other projects > which depend on languages not implemented by GCC. > * Support for older platforms which ONLY support gcc. > > So, I apologize if I don't agree with the "nothing to gain" opinion. > Yours, GC > -- > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > http://ind.ie/phoenix/ > -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/
