No Asbestos required - but .. I do have some observations..
I write pretty much all my serious (day-job) code in ObjC and..
... I have stated that it's an intention to make *that*, at least
work at V2 on FSF.
Having said that:
a) I have not anything like as much attachment to ObjC++ ...
b) We are all limited in the amount of time we can allocate to FSF ..
Progress can be limited almost as much by the review lag as it is by
technical difficulty in fixing the problems.
On 20 May 2010, at 20:02, Steven Bosscher wrote:
The Obj-C++ front end is effectively unmaintained, and has virtually
no serious users. I propose to remove it from GCC.
a) I'm curious about how we know how many actual users we have.
b) The largest group of potential users is on OSX - and, of course,
without NeXT working on 64bit that's a serious limitation.
yay verily the chicken and the egg.
Also, I think it fair to say that "ordinary" users - like me have been
reluctant to devote significant time to ObjC/C++
... when the likelihood of getting code accepted was c.f sqrt(0.0).
I would suggest that, if we achieve V2 NeXT support and detachment
from corporate domination of maintainers ... we might fare better.
(but perhaps it's just not a popular language full stop).
Perhaps the only user of some significance is GNUstep, but they are
already in an awkward position because they wish to use ObjC 2.0, and
they are looking at clang for that.
I am under the impression from the 4.2 code-base that V2.0 ObjC++ will
come pretty much for free with V2 ObjC.
The burden on GCC on the other hand, from a maintainer's point of
view, is very significant.
high maintenance != unmaintained ;-)
The Obj-C++ front end ties
together the c, objc, and g++ front ends in very uncomfortable ways.
doesn't it just :-( ... it's a nightmare to learn (1st hand
experience).
It would be worth pausing to see if there's a way to disentangle it.
Which would, perhaps, go some way towards ameliorating the irritation.
There are also technical reasons for removing this front end. For one,
objc exceptions in objc++ don't work for the GNU runtime.
Well .. I have an opinion that don't != can't ... if you know this
to be untrue I'd be interested.
... ObjC exceptions need sorting out..
I would hope that ObjC++ exceptions would 99% fall out of that.
The implementation of the language also appears to be out of sync with
Apple (apart from ObjC 2.0).
I'm not aware of any excess lack of sync c.f. ObjC
V1 requires FE __attribute__ and @property support (which I've got 95%
working on a local tree)
V2 - I guess the most significant impact is gc.
I'll get in my flame resistant suit now...
So what about writing an Occam FE ;-) ?
Iain
