Zem --
The SC has decided to accept Objective-C++, in principle. However,
there are a few steps that must be taken before that can happen.
First, the SC wants reasonable documentation for Objective-C++ to be
made available. There's an understanding that Apple may not have a
specification that is at the level of an ISO standard; a user's manual
or reference guide is OK.
Second, the documentation requirements for any GCC patch must be met.
These include changes to the manuals mentioning
Objective-C++describing any Objective-C++ command-line options. Also,
every new function must have a comment that explicitly describes how
each parameter is used and what the function returns.
When these two requires are satisfied, please post a patch. Please
copy Joseph Myers, Jason Merrill and myself; hopefully between the
three of us we can get it reviewed relatively quickly.
Objective-C++ will not be considered when making releases. The state
of Objective-C++ will be irrelevant when deciding whether or not to
make a release. However, the SC hopes that Apple will provide
resources to ensure that Objective-C++ stays in reasonable shape.
Furthermore, nobody will be required to test Objective-C++ as part of
the check-in cycle, and people who cause defects in Objective-C++ will
not necessarily be required to fix them, although good manners
dictates that people will help clean up their own mess where
practical. The default configuration for GCC should not include
Objective-C++; a user who wants Objective-C++ should explicitly use
--enable-languages.
The rationale for this compromise position is that the SC feels that,
on the one hand, it would be unfair to turn away Apple's contribution.
On the other, the SC is concerned about possible maintenance issues.
The approach outlined above allows Apple to contribute Objective-C++,
but also reflects the expectation that Apple will be largely
responsible for the maintenance of Objective-C++.
Yours,
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com