<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.6: http://docutils.sourceforge.net/" />
<title>Keywords for override control</title>
<meta name="date" content="2010-10-07" />
<meta name="authors" content="Ville Voutilainen &lt;ville.voutilainen&#64;gmail.com&gt;" />
<style type="text/css">

/*
:Author: David Goodger (goodger@python.org)
:Id: $Id: html4css1.css 5951 2009-05-18 18:03:10Z milde $
:Copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.

See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
customize this style sheet.
*/

/* used to remove borders from tables and images */
.borderless, table.borderless td, table.borderless th {
  border: 0 }

table.borderless td, table.borderless th {
  /* Override padding for "table.docutils td" with "! important".
     The right padding separates the table cells. */
  padding: 0 0.5em 0 0 ! important }

.first {
  /* Override more specific margin styles with "! important". */
  margin-top: 0 ! important }

.last, .with-subtitle {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dl.docutils dd {
  margin-bottom: 0.5em }

/* Uncomment (and remove this text!) to get bold-faced definition list terms
dl.docutils dt {
  font-weight: bold }
*/

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.admonition, div.attention, div.caution, div.danger, div.error,
div.hint, div.important, div.note, div.tip, div.warning {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.admonition p.admonition-title, div.hint p.admonition-title,
div.important p.admonition-title, div.note p.admonition-title,
div.tip p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

/* Uncomment (and remove this text!) to get reduced vertical space in
   compound paragraphs.
div.compound .compound-first, div.compound .compound-middle {
  margin-bottom: 0.5em }

div.compound .compound-last, div.compound .compound-middle {
  margin-top: 0.5em }
*/

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em ;
  margin-right: 2em }

div.footer, div.header {
  clear: both;
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin: 0 0 0.5em 1em ;
  border: medium outset ;
  padding: 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
  margin-top: 0.4em }

h1.title {
  text-align: center }

h2.subtitle {
  text-align: center }

hr.docutils {
  width: 75% }

img.align-left, .figure.align-left{
  clear: left ;
  float: left ;
  margin-right: 1em }

img.align-right, .figure.align-right {
  clear: right ;
  float: right ;
  margin-left: 1em }

.align-left {
  text-align: left }

.align-center {
  clear: both ;
  text-align: center }

.align-right {
  text-align: right }

/* reset inner alignment in figures */
div.align-right {
  text-align: left }

/* div.align-center * { */
/*   text-align: left } */

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font: inherit }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em }

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

span.section-subtitle {
  /* font-size relative to parent (h1..h6 element) */
  font-size: 80% }

table.citation {
  border-left: solid 1px gray;
  margin-left: 1px }

table.docinfo {
  margin: 2em 4em }

table.docutils {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.footnote {
  border-left: solid 1px black;
  margin-left: 1px }

table.docutils td, table.docutils th,
table.docinfo td, table.docinfo th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

table.docutils th.field-name, table.docinfo th.docinfo-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap ;
  padding-left: 0 }

h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
  font-size: 100% }

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="keywords-for-override-control">
<h1 class="title">Keywords for override control</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Date:</th>
<td>2010-10-07</td></tr>
<tr><th class="docinfo-name">Version:</th>
<td>N3151=10-0141</td></tr>
<tr><th class="docinfo-name">Authors:</th>
<td>Ville Voutilainen &lt;<a class="reference external" href="mailto:ville.voutilainen&#64;gmail.com">ville.voutilainen&#64;gmail.com</a>&gt;</td></tr>
</tbody>
</table>
<div class="abstract topic">
<p class="topic-title first">Abstract</p>
<p>Multiple National Bodies requested in their FCD ballot
responses that the virtual override control attributes
are turned into keywords. The related NB comments are US 44
and CA 3. This paper proposes an analysis of whether
to strive for using context-sensitive keywords or normal
keywords (note that the CWG straw poll consensus was towards
normal keywords). Note that this paper doesn't consider
alignment facilities, but focuses on virtual override
facilities. The solution proposed in this paper is using
normal keywords as opposed to context-sensitive ones,
and putting such keywords at the end of a declaration.</p>
</div>
<div class="section" id="background">
<h1>Background</h1>
<p>Currently the virtual override control attribute example looks as follows:</p>
<pre class="literal-block">
class B {
   virtual void some_func();

   virtual void f(int);
   virtual void h(int);
   void j(int);
   void k();
   typedef B self;
};

class D [[base_check]] : public B {
   void sone_func [[override]] ();          // error: mis-spelled name

   void f [[override]] (int);               // ok: f implicitly virtual, overrides B::f
   virtual void f [[override]] (long);      // error: non-matching argument type
   virtual void f [[override]] (int) const; // error: non-matching cv-qualification
   virtual int  f [[override]] (int);       // error: non-matching return type

   virtual void g(long);      // ok: new virtual function introduced

   void h(int);               // error: h implicitly virtual, but overriding without marker
   virtual void h(double);    // error: hides B::h without marker
   virtual void h [[hiding]] (char *);      // ok

   using B::j;
   int j(double);                   // ok: not hiding due to &quot;using&quot;
   void j(int);                     // ok, despite 'obscuring' B::j(int)
   virtual int j [[hiding]] (void); // error: not hiding due to &quot;using&quot;

   int k;                           // error: hides B::k without marker

   int m [[hiding]] ( int );        // error: no hiding despite marker
   typedef D self;                  // error: hides B::self without marker
};
</pre>
<p>As a response to the CD ballot, NB comments US 41 and FI 1 requested
for a facility to be able to mark intended overrides and have the
implementation to check whether functions so marked are actually
overrides. As a solution, the paper N2928 was produced, and the
solution proposed in that paper was ultimatedly adopted and is
currently part of the FCD.</p>
<p>Several experts have lamented the solution, saying that it
uses attributes for semantic effects and that the language
shouldn't use such semantic effects itself as that sets
a bad example. Furthermore many people consider the attributes
ugly. As a response to the FCD ballot, NB comments
US 44 and CA 3 requested that the virtual override control
attributes be changed to keywords. The CWG had a discussion
on these NB comments, and the straw poll results were as
follows:</p>
<blockquote>
<ul class="simple">
<li>Straw poll: override control (including final) as real keywords: 6 SF, 10 WF, 5 WA, 0 SA</li>
<li>Straw poll: override control (including final) as contextual keywords: 6 SF, 7 WF, 2 WA, 5 SA</li>
<li>Straw poll: override control (including final) as attributes: 1 SF, 6 WF, 3 WA, 10 SA</li>
</ul>
</blockquote>
<p>According to this straw poll, this paper analyzes both context-sensitive
and normal keywords as possible solutions.</p>
<p>Languages like Java and C# have final (or in C#, sealed) as a keyword.
C# additionally has override, whereas Java uses an annotation for override.
C++/CLI has both sealed and override as keywords, but chooses to place
such keywords at the end of a function declaration rather than at the
beginning. Examples of these follow.</p>
<p>Java example:</p>
<pre class="literal-block">
public class base
{
    public final void f() {/*...*/}
    public void g() {/*...*/}
}

public class derived extends base
{
    // can't override f()
    &#64;Override
    public void g() {/*...*/}
}
</pre>
<p>C# example:</p>
<pre class="literal-block">
public class base
{
    public sealed void f() {/*...*/}
    public virtual void g() {/*...*/}
}

public class derived : base
{
    // can't override f()
    public override void g() {/*...*/}
}
</pre>
<p>C++/CLI example:</p>
<pre class="literal-block">
public ref class base
{
public:
    virtual void f() sealed {/*...*/}
    virtual void g() {/*...*/}
};

public ref class derived : public base
{
public:
    // can't override f()
    void g() override {/*...*/}
};
</pre>
</div>
<div class="section" id="solution-analysis-with-context-sensitive-keywords">
<h1>Solution analysis with context-sensitive keywords</h1>
<p>The main benefit of having context-sensitive keywords
would be that they can appear only in certain contexts,
and thus pose a smaller risk of breaking existing code.</p>
<p>While Java and C# place the keywords in positions different
than C++/CLI, it can be argued that C++/CLI is at least
an example of implementation experience for such keywords
as context-sensitive keywords. They have been shipped in
products for several years, and developer feedback based
on field experience is very positive.</p>
<p>The example with such keywords would look somewhat similar to C++/CLI:</p>
<pre class="literal-block">
class base
{
public:
    virtual void f() final_overrider {/*...*/}
    virtual void g() {/*...*/}
};

class derived : public base
{
public:
    // can't override f()
    void g() virtual_override {/*...*/}
};
</pre>
<p>It is preferrable to put such virtual control keywords
at the end of the declaration so that they don't clash
with eg. return types at the beginning of declarations.</p>
<p>Daveed Vandevoorde pointed out the following problem
with context-sensitive keyword, or specifically the
facility to be able to mark cases where names are hidden:</p>
<pre class="literal-block">
struct Z {};
struct X
{
  // what does this mean?
  // is it a struct declaration
  // or a variable declaration?
  struct Z hides_name;
};

struct C {};
struct A
{
  typedef int C;
};

struct B : A
{
  // looks like we forward-declare a struct
  // that hides the name C? Or are we declaring
  // a variable?
  struct C hides_name;
};

// is this the solution?
struct B : A
{
  hides_name struct hides_name C p;
};
</pre>
<p>The gist of the example is that for the name-hiding facility,
it's sometimes still difficult to know to which name the keyword
appertains. Attributes don't suffer from such problems since
wherever they were able to appear, they didn't clash with
names in such a manner, and the rules for appertaining were clear.</p>
</div>
<div class="section" id="solution-analysis-with-normal-keywords">
<h1>Solution analysis with normal keywords</h1>
<p>For context-insensitive, normal keywords, it's less important
where the keywords are placed because the words are reserved.
We could put them at the beginning of declarations or at the
end.</p>
<p>During the discussion of attributes, Francis Glassborow pointed
out that the beginning of declarations is becoming crowded. If
we put the virtual control keywords at the beginning, we can
end up with examples like the one below:</p>
<pre class="literal-block">
struct B
{
   virtual volatile const unsigned long int f()
      volatile const noexcept;
   void f(int g);
};

struct D : B
{
   virtual hides_name virtual_override final_overrider volatile const unsigned long int f()
      volatile const noexcept;
};
</pre>
<p>Putting the new keywords at the end at least alleviates the situation
somewhat:</p>
<pre class="literal-block">
struct B
{
   virtual volatile const unsigned long int f()
      volatile const noexcept;
   void f(int g);
};

struct D : B
{
   virtual volatile const unsigned long int f()
      hides_name virtual_override final_overrider volatile const noexcept;
};
</pre>
<p>There are people who think these control keywords should be in the
same place with virtual. As mentioned, that place is already
crowded.</p>
</div>
<div class="section" id="painting-the-bikeshed">
<h1>Painting the bikeshed</h1>
<p>The initial proposal posted on the mailing list was as follows:</p>
<table border="1" class="docutils">
<colgroup>
<col width="33%" />
<col width="67%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Attribute</th>
<th class="head">Keyword</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>[[override]]</td>
<td>virtual_override</td>
</tr>
<tr><td>[[final]]</td>
<td>final_overrider</td>
</tr>
<tr><td>[[hiding]]</td>
<td>hiding_name</td>
</tr>
<tr><td>[[base_check]]</td>
<td>verify_decls/check_name_decls</td>
</tr>
</tbody>
</table>
<p>Daveed Vandevoorde suggested the following:</p>
<table border="1" class="docutils">
<colgroup>
<col width="33%" />
<col width="67%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Attribute</th>
<th class="head">Keyword</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>[[override]]</td>
<td>override_virtual</td>
</tr>
<tr><td>[[final]]</td>
<td>final_virtual</td>
</tr>
<tr><td>[[hiding]]</td>
<td>hiding_name</td>
</tr>
<tr><td>[[base_check]]</td>
<td>explicit class/struct</td>
</tr>
</tbody>
</table>
<p>For &quot;override_virtual&quot; and &quot;final_virtual&quot;
he said that the current virtual keyword would not be needed in these cases
but would rather be banned for these cases.
He also suggested that the keywords
be placed at the beginning of a declaration.</p>
<p>Bjarne Stroustrup suggested the following colors for the shed:</p>
<table border="1" class="docutils">
<colgroup>
<col width="41%" />
<col width="59%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Attribute</th>
<th class="head">Keyword</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>[[override]]</td>
<td>override/do_override</td>
</tr>
<tr><td>[[final]]</td>
<td>no_override</td>
</tr>
<tr><td>[[hiding]]</td>
<td>do_hide/hides</td>
</tr>
<tr><td>[[base_check]]</td>
<td>base_check</td>
</tr>
</tbody>
</table>
<p>Mike Spertus contributed the following hues:</p>
<table border="1" class="docutils">
<colgroup>
<col width="41%" />
<col width="59%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Attribute</th>
<th class="head">Keyword</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>[[override]]</td>
<td>override_method</td>
</tr>
<tr><td>[[final]]</td>
<td>final_method</td>
</tr>
<tr><td>[[hiding]]</td>
<td>hide_method</td>
</tr>
<tr><td>[[base_check]]</td>
<td>base_check</td>
</tr>
</tbody>
</table>
<p>He later contributed another proposal:</p>
<table border="1" class="docutils">
<colgroup>
<col width="41%" />
<col width="59%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Attribute</th>
<th class="head">Keyword</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>[[override]]</td>
<td>override_member</td>
</tr>
<tr><td>[[final]]</td>
<td>final_member</td>
</tr>
<tr><td>[[hiding]]</td>
<td>hide_member</td>
</tr>
</tbody>
</table>
<p>Herb Sutter contributed the following palette:</p>
<table border="1" class="docutils">
<colgroup>
<col width="41%" />
<col width="59%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Attribute</th>
<th class="head">Keyword</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>[[override]]</td>
<td>override_it</td>
</tr>
<tr><td>[[final]]</td>
<td>finalize_it</td>
</tr>
<tr><td>[[hiding]]</td>
<td>hide_it</td>
</tr>
</tbody>
</table>
</div>
<div class="section" id="discussion-about-the-solutions">
<h1>Discussion about the solutions</h1>
<p>Regardless of whether we ultimately choose to use context-sensitive
or normal keywords, it would be prudent to choose keywords that aren't
used in existing code, so as to not confuse the user. For any normal
keywords, we must pick ones that are not widely used.</p>
<p>Due to the problem depicted by Daveed, and due to the guidance given
by straw polls, it seems like normal keywords as opposed to
context-sensitive ones are the path forward.</p>
</div>
<div class="section" id="proposal">
<h1>Proposal</h1>
<p>Use normal keywords, as they don't suffer from the problem depicted
by Daveed, and place the keywords at the end of a declaration.
Thus far we have just done Google Code Searches, and while it's
a huge question of opinion which keywords to choose, here is
an initial proposal:</p>
<table border="1" class="docutils">
<colgroup>
<col width="47%" />
<col width="53%" />
</colgroup>
<thead valign="bottom">
<tr><th class="head">Attribute</th>
<th class="head">Keyword</th>
</tr>
</thead>
<tbody valign="top">
<tr><td>[[override]]</td>
<td>ovrdecl</td>
</tr>
<tr><td>[[final]]</td>
<td>finaldecl</td>
</tr>
<tr><td>[[hiding]]</td>
<td>hidedecl</td>
</tr>
<tr><td>[[base_check]]</td>
<td>strictdecl</td>
</tr>
</tbody>
</table>
<p>With this proposal, the attribute example in FCD would look
like this:</p>
<pre class="literal-block">
class B {
   virtual void some_func();

   virtual void f(int);
   virtual void h(int);
   void j(int);
   void k();
   typedef B self;
};

class D strictdecl : public B {
   void sone_func() ovrdecl;          // error: mis-spelled name

   void f(int) ovrdecl;               // ok: f implicitly virtual, overrides B::f
   virtual void f(long) ovrdecl;      // error: non-matching argument type
   virtual void f(int) ovrdecl const; // error: non-matching cv-qualification
   virtual int  f(int) ovrdecl;       // error: non-matching return type

   virtual void g(long);      // ok: new virtual function introduced

   void h(int);               // error: h implicitly virtual, but overriding without marker
   virtual void h(double);    // error: hides B::h without marker
   virtual void h(char *) hidedecl;      // ok

   using B::j;
   int j(double);                   // ok: not hiding due to &quot;using&quot;
   void j(int);                     // ok, despite 'obscuring' B::j(int)
   virtual int j(void) hidedecl; // error: not hiding due to &quot;using&quot;

   int k;                           // error: hides B::k without marker

   int m(int) hidedecl;        // error: no hiding despite marker
   typedef D self;                  // error: hides B::self without marker
};
</pre>
</div>
</div>
</body>
</html>
