public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Mark Mitchell <mark@markmitchell.com>
To: Jan.Madsen@epfl.ch
Cc: egcs@cygnus.com
Subject: Re: Patch for sC++ to GNU C++.
Date: Wed, 21 Oct 1998 22:10:00 -0000	[thread overview]
Message-ID: <199810212214.PAA16044@smtp.earthlink.net> (raw)
In-Reply-To: <362D8C74.ADBC2FAE@epfl.ch>

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

  parent reply	other threads:[~1998-10-21 22:10 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-10-21  3:27 Jan Madsen
1998-10-21 19:20 ` Joe Buck
1998-10-22 11:32   ` Mark Mitchell
1998-10-22 18:00     ` Joe Buck
1998-10-22 21:15       ` Jan Madsen
1998-10-22 22:22       ` Mark Mitchell
1998-10-22 18:00         ` Joe Buck
1998-10-22 13:59           ` Mark Mitchell
1998-10-22 21:15             ` Joe Buck
1998-10-23  4:36               ` Jan Madsen
1998-10-25 13:53                 ` Jeffrey A Law
1998-10-22 21:15     ` Chip Salzenberg
1998-10-21 22:10 ` Mark Mitchell [this message]
     [not found] ` <199810212214.PAA16044.cygnus.egcs@smtp.earthlink.net>
1998-10-22 22:22   ` Jason Merrill
1998-10-25 18:03 ` Ken Raeburn
1998-10-22 13:59 Mike Stump
1998-11-13  5:01 Jan Madsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199810212214.PAA16044@smtp.earthlink.net \
    --to=mark@markmitchell.com \
    --cc=Jan.Madsen@epfl.ch \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).