Re: RFC: New C++ Attribute: final

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Tue, Mar 02, 2004 at 12:57:21PM -0800, Matt Austern wrote:
> My opinion is that this would be better sent to the C++ standards
> committee than to the gcc mailing list.  That is: I would be much
> happier if this were part of portable C++ than if we put it in as an
> ad hoc extension.

I think that anything that we implement should be specified well enough
so that the spec could serve as draft language for an extension to the
standard.  However, given such language, it certainly makes sense to
be able to demonstrate the proposed extension with a working
implementation.  A number of features now present in C99 or ISO C++
were originally GCC extensions, though in many cases the final form
did not quite match the original GCC extension.  Examples include
variable-length arrays in C, and the ability to define class constants
in the class body in C++.  If GCC switches to such a firm anti-extension
policy that such features are not considered in the future, and just
leave language committees to specify new features that have never seen
use, this will harm the quality of future language standards.

So we need to strike a balance.

> Rationale: our experiences with language-design-by-compiler
> have been mixed.  It's unlikely that we'll be able to get all of the
> corner cases on a new language feature right if we just say "this
> feature should do thus-and-such for this example", because we
> have to know what it does for code other than whatever is in a
> finite number of examples.  And C++ is a complicated enough
> language that a new feature is likely to have corner cases and
> non-obvious interactions with other features, even if it seems
> simple at first.

I think that we should not close the door for use of GCC as a testbed,
but we should set a high standard.  In the case of extensions I think
that we should require a document along with any proposed patch, and
have some review of the document before bothering with reviewing the
patch.  The document should be in the form of a proposal to extend the
standard to accept the extension, meaning that it has to address
interactions with other language features.  The proposal doesn't have
to be rock-solid final standardese at the time the patch is accepted, but
it should answer the questions that the reviewers can come up with.

In the case of "final", the good news is that there is a lot of prior
art; in particular, the meaning of "final" in Java, where the keyword can
be applied either to a class or to a member function.  Someone proposing
"final" could start from there, then see if there are any additional
interactions in C++.  I can think of one:

- nonvirtual functions.  If a nonvirtual function is overridden by a
  "final" function in the derived class, should we object?  (This can't
  happen in Java).