This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for sC++ to GNU C++.
- To: Jan dot Madsen at epfl dot ch
- Subject: Re: Patch for sC++ to GNU C++.
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Wed, 21 Oct 1998 15:14:18 -0700
- CC: egcs at cygnus dot com
- References: <362D8C74.ADBC2FAE@epfl.ch>
- Reply-to: mark at markmitchell dot com
I am very nervous about extensions to languages, especially C++.
That's not because I doubt the skill of the implementors of these
extensions, or the design of the extensions themselves, or even the
utility of the extensions; it's because every extension puts a large
burden on those of us working on the "core" language.
In particular, we have to learn about these extensions an bear them in
mind whenever we make changes. As an example, take the g++
`signature' extension. I must keep signatures in mind whenever I make
changes, and I have sometimes broken signatures without breaking
anything else simply because I forgot to bear in mind various quirks
of signatures and their implementation.
FWIW, I recommend that we stay away from any and all non-trivial
extensions to C++ until we complete work on the features core
language. We've still got work to do with namespaces, `export', other
template features, using declarations, etc.
Lest any devil's advocates out there complain that I propose to add
`__restrict__' to C++, note that I consider `__restrict__' a "trivial"
extension to C++ since it will be handled by first simplifying the C++
front-end to deal with type qualifiers, and then by adding `restrict'
to the set of type qualifiers. So, in fact, the code will become
simpler, not more complex, and the total overhead for `restrict' will
be approximately 10 lines of code in the C++ front-end.
Obviously, these opinions (both the triviality of `restrict' and the
aversion to C++ extensions) are my own, and represent nothing about
the will of the EGCS steering committee, or that of the C++
front-end maintainer.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com