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/

Reply via email to