C++11 adds final and override, but there is still no way to require that
a declaration introduces a new virtual interface and does not override a
base class. I propose to use the ! operator (or the "not" alternative
punctuator) as a modifier to the existing virt-specifiers, with the
effect of negating their requirements. So this example would be
ill-formed if the template parameter "b" has a virtual member function
void fn(int).

template< typename b >
struct base : b {
     virtual void fn( int ) not override {
         std::cout << "Default base::fn, not some name collision\n";
     }
};

The "not final" virt-specifier would signify a pure virtual function (or
abstract class), but syntactically would still allow a function-body,
which the "= 0" syntax does not. It would also be less cryptic and more
expository, and "= 0" could be deprecated as a relic oddball.

template< typename b >
struct abstract_base : b {
     virtual void fn( int ) not override not final {
         std::cout << "Statically dispatched or ctor/dtor base::fn, and
not a name collision\n";
     }
};

abstract_base x; // Error: pure virtual function "fn" not implemented.

I don't really plan on making a formal proposal any time soon, so please
feel free to pick this up if you like the idea.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On s=E1bado, 9 de novembro de 2013 13:03:01, David Krauss wrote:
> The "not final" virt-specifier would signify a pure virtual function (or=
=20
> abstract class), but syntactically would still allow a function-body,=20
> which the "=3D 0" syntax does not

It does. It just can't be in the class declaration.

struct K
{
    virtual void f() =3D 0;
};

void K::f() {}

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 11/9/13 2:04 PM, Thiago Macieira wrote:
> On s=E1bado, 9 de novembro de 2013 13:03:01, David Krauss wrote:
>> The "not final" virt-specifier would signify a pure virtual function (or
>> abstract class), but syntactically would still allow a function-body,
>> which the "=3D 0" syntax does not
> It does. It just can't be in the class declaration.

What I said is, the syntax "=3D 0" cannot be combined syntactically with a=
=20
function-body. Your example has them syntactically separate in two=20
declarations.

If abstract discussion of the syntax reminds us of something confusing,=20
then perhaps there is something to fix.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a1134a0cad40d3004eabdac2b
Content-Type: text/plain; charset=ISO-8859-1

On 9 November 2013 07:03, David Krauss <potswa@gmail.com> wrote:

> C++11 adds final and override, but there is still no way to require that a
> declaration introduces a new virtual interface and does not override a base
> class. I propose to use the ! operator (or the "not" alternative
> punctuator) as a modifier to the existing virt-specifiers, with the effect
> of negating their requirements. So this example would be ill-formed if the
> template parameter "b" has a virtual member function void fn(int).
>
> template< typename b >
> struct base : b {
>     virtual void fn( int ) not override {
>         std::cout << "Default base::fn, not some name collision\n";
>     }
> };
>
>
What would be the practical need for being able to say that you introduce a
new virtual
function that is not an override?



> The "not final" virt-specifier would signify a pure virtual function (or
> abstract class), but syntactically


I don't think that's right. A non-final virtual function is not necessarily
pure, this is mixing separate
concepts.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1134a0cad40d3004eabdac2b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 November 2013 07:03, David Krauss <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">C++11 adds final and override, but there is =
still no way to require that a declaration introduces a new virtual interfa=
ce and does not override a base class. I propose to use the ! operator (or =
the &quot;not&quot; alternative punctuator) as a modifier to the existing v=
irt-specifiers, with the effect of negating their requirements. So this exa=
mple would be ill-formed if the template parameter &quot;b&quot; has a virt=
ual member function void fn(int).<br>

<br>
template&lt; typename b &gt;<br>
struct base : b {<br>
=A0 =A0 virtual void fn( int ) not override {<br>
=A0 =A0 =A0 =A0 std::cout &lt;&lt; &quot;Default base::fn, not some name co=
llision\n&quot;;<br>
=A0 =A0 }<br>
};<br>
<br></blockquote><div><br></div><div>What would be the practical need for b=
eing able to say that you introduce a new virtual<br>function that is not a=
n override?<br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

The &quot;not final&quot; virt-specifier would signify a pure virtual funct=
ion (or abstract class), but syntactically </blockquote><div><br></div><div=
>I don&#39;t think that&#39;s right. A non-final virtual function is not ne=
cessarily pure, this is mixing separate<br>
concepts. <br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1134a0cad40d3004eabdac2b--

.

------=_Part_1123_8577513.1384003845054
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le samedi 9 novembre 2013 13:31:16 UTC+1, Ville Voutilainen a =E9crit :
>
>
> On 9 November 2013 07:03, David Krauss <pot...@gmail.com <javascript:>>wr=
ote:
>
>> C++11 adds final and override, but there is still no way to require that=
=20
>> a declaration introduces a new virtual interface and does not override a=
=20
>> base class. I propose to use the ! operator (or the "not" alternative=20
>> punctuator) as a modifier to the existing virt-specifiers, with the effe=
ct=20
>> of negating their requirements. So this example would be ill-formed if t=
he=20
>> template parameter "b" has a virtual member function void fn(int).
>>
>> template< typename b >
>> struct base : b {
>>     virtual void fn( int ) not override {
>>         std::cout << "Default base::fn, not some name collision\n";
>>     }
>> };
>>
>>
> What would be the practical need for being able to say that you introduce=
=20
> a new virtual
> function that is not an override?
>
>
My guess is avoiding name clashes introduced by evolution (a base class=20
introduces a virtual
function with the same name and signature than one you have already in=20
yours).  I'm not really
convinced (that seems a recipe for confusion) but when you are both a=20
client with little control
on the base class and a provider with strong incentive for backward=20
compatibility that may be
the less bad of several bad solutions.

With some work and an additional class, it could be used also to provide a=
=20
way of ensuring that
your descendants respect the constraint you want to push on their override=
=20
while respecting=20
the published interface for your Base (but the constraint will be respected=
=20
that only for calls
when the static type is Base, that seems again.a recipe for confusion even=
=20
if there are patterns
where it is always the case).

struct Helper: Base {
   int fn(int i) final { return Helper_fn(i); }
   virtual int Helper_fn(int) =3D 0;
};

struct MyClass: Helper {
   virtual int fn(int i) not override { return i; };
   virtual int Helper_fn(int i) final {
      prefn(i);
      return postfn(fn(i), i);
   }
   // define prefn and postfn here
};

Yours,

--=20
Jean-Marc

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1123_8577513.1384003845054
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Le samedi 9 novembre 2013 13:31:16 UTC+1, Ville Voutilaine=
n a =E9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><br><div class=3D"gmail_quote">On 9 November 2013 07:03, David Kr=
auss <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"aTUPPYr1gg4J">pot...@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">C++11 adds final and override, but there is =
still no way to require that a declaration introduces a new virtual interfa=
ce and does not override a base class. I propose to use the ! operator (or =
the "not" alternative punctuator) as a modifier to the existing virt-specif=
iers, with the effect of negating their requirements. So this example would=
 be ill-formed if the template parameter "b" has a virtual member function =
void fn(int).<br>

<br>
template&lt; typename b &gt;<br>
struct base : b {<br>
&nbsp; &nbsp; virtual void fn( int ) not override {<br>
&nbsp; &nbsp; &nbsp; &nbsp; std::cout &lt;&lt; "Default base::fn, not some =
name collision\n";<br>
&nbsp; &nbsp; }<br>
};<br>
<br></blockquote><div><br></div><div>What would be the practical need for b=
eing able to say that you introduce a new virtual<br>function that is not a=
n override?</div><br></div></div></div></blockquote><div><br>My guess is av=
oiding name clashes introduced by evolution (a base class introduces a virt=
ual<br>function with the same name and signature than one you have already =
in yours).&nbsp; I'm not really<br>convinced (that seems a recipe for confu=
sion) but when you are both a client with little control<br>on the base cla=
ss and a provider with strong incentive for backward compatibility that may=
 be<br>the less bad of several bad solutions.<br><br>With some work and an =
additional class, it could be used also to provide a way of ensuring that<b=
r>your descendants respect the constraint you want to push on their overrid=
e while respecting <br>the published interface for your Base (but the const=
raint will be respected that only for calls<br>when the static type is Base=
, that seems again.a recipe for confusion even if there are patterns<br>whe=
re it is always the case).<br><br><div style=3D"text-align: left;"><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Helper</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Base</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
&nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fn<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">final</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Helper_fn</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Helper_fn</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">MyClass</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Helper</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>&nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">virtual</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> fn</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">not</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
override</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">Helper_fn</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">final</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; &nbsp; prefn</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> postfn</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">fn</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp;</span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// define prefn and postfn here</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div></div><br>Yo=
urs,<br><br>-- <br>Jean-Marc<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1123_8577513.1384003845054--

.

--001a113448745f70e204eabf3ba7
Content-Type: text/plain; charset=ISO-8859-1

On 9 November 2013 15:30, Jean-Marc Bourguet <jm.bourguet@gmail.com> wrote:

>
>
>> What would be the practical need for being able to say that you introduce
>> a new virtual
>> function that is not an override?
>>
>>
> My guess is avoiding name clashes introduced by evolution (a base class
> introduces a virtual
> function with the same name and signature than one you have already in
> yours).  I'm not really
> convinced (that seems a recipe for confusion) but when you are both a
> client with little control
> on the base class and a provider with strong incentive for backward
> compatibility that may be
> the less bad of several bad solutions.
>

I suppose a class template with a dependent base class would further
decrease the
amount of control on the base class in such a case.


> With some work and an additional class, it could be used also to provide a
> way of ensuring that
> your descendants respect the constraint you want to push on their override
> while respecting
> the published interface for your Base (but the constraint will be
> respected that only for calls
> when the static type is Base, that seems again.a recipe for confusion even
> if there are patterns
> where it is always the case).
>
> struct Helper: Base {
>    int fn(int i) final { return Helper_fn(i); }
>    virtual int Helper_fn(int) = 0;
> };
>
> struct MyClass: Helper {
>    virtual int fn(int i) not override { return i; };
>    virtual int Helper_fn(int i) final {
>       prefn(i);
>       return postfn(fn(i), i);
>    }
>    // define prefn and postfn here
> };
>
>
>
I have done something quite similar, make a virtual drawing function in a
UI control hierarchy
final, and introduce a new one that the derived classes should override. It
would certainly
have been convenient to not have to introduce a new virtual function and
have magic just
happen, but I'm not convinced we need to support such cases. And on the
other hand,
I think it was also convenient that the magic couldn't happen and the new
function
was introduced. C# does support such magic, though, afaik. Their 'new' does
the same
thing as that proposed 'not override', whereas the [[new]] that was at some
point part
of the virtual control attributes proposed for C++11 would've meant 'not
hiding'.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113448745f70e204eabf3ba7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 9 November 2013 15:30, Jean-Marc Bourguet <span dir=3D"ltr">&lt;=
<a href=3D"mailto:jm.bourguet@gmail.com" target=3D"_blank">jm.bourguet@gmai=
l.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"im"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>What w=
ould be the practical need for being able to say that you introduce a new v=
irtual<br>function that is not an override?</div><br></div></div></div></bl=
ockquote>
</div><div><br>My guess is avoiding name clashes introduced by evolution (a=
 base class introduces a virtual<br>function with the same name and signatu=
re than one you have already in yours).=A0 I&#39;m not really<br>convinced =
(that seems a recipe for confusion) but when you are both a client with lit=
tle control<br>
on the base class and a provider with strong incentive for backward compati=
bility that may be<br>the less bad of several bad solutions.<br></div></div=
></blockquote><div><br></div><div>I suppose a class template with a depende=
nt base class would further decrease the<br>
amount of control on the base class in such a case.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div><br>With some work and an additi=
onal class, it could be used also to provide a way of ensuring that<br>
your descendants respect the constraint you want to push on their override =
while respecting <br>the published interface for your Base (but the constra=
int will be respected that only for calls<br>when the static type is Base, =
that seems again.a recipe for confusion even if there are patterns<br>
where it is always the case).<br><br><div style=3D"text-align:left"><div st=
yle=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);bord=
er-style:solid;border-width:1px;word-wrap:break-word"><code><div><span styl=
e=3D"color:#008">struct</span><span style> </span><span style=3D"color:#606=
">Helper</span><span style=3D"color:#660">:</span><span style> </span><span=
 style=3D"color:#606">Base</span><span style> </span><span style=3D"color:#=
660">{</span><span style><br>
=A0 =A0</span><span style=3D"color:#008">int</span><span style> fn</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#008">int</span><span=
 style> i</span><span style=3D"color:#660">)</span><span style> </span><spa=
n style=3D"color:#008">final</span><span style> </span><span style=3D"color=
:#660">{</span><span style> </span><span style=3D"color:#008">return</span>=
<span style> </span><span style=3D"color:#606">Helper_fn</span><span style=
=3D"color:#660">(</span><span style>i</span><span style=3D"color:#660">);</=
span><span style> </span><span style=3D"color:#660">}</span><span style><br=
>
=A0 =A0</span><span style=3D"color:#008">virtual</span><span style> </span>=
<span style=3D"color:#008">int</span><span style> </span><span style=3D"col=
or:#606">Helper_fn</span><span style=3D"color:#660">(</span><span style=3D"=
color:#008">int</span><span style=3D"color:#660">)</span><span style> </spa=
n><span style=3D"color:#660">=3D</span><span style> </span><span style=3D"c=
olor:#066">0</span><span style=3D"color:#660">;</span><span style><br>
</span><span style=3D"color:#660">};</span><span style><br><br></span><span=
 style=3D"color:#008">struct</span><span style> </span><span style=3D"color=
:#606">MyClass</span><span style=3D"color:#660">:</span><span style> </span=
><span style=3D"color:#606">Helper</span><span style> </span><span style=3D=
"color:#660">{</span><span style><br>
=A0 =A0</span><span style=3D"color:#008">virtual</span><span style> </span>=
<span style=3D"color:#008">int</span><span style> fn</span><span style=3D"c=
olor:#660">(</span><span style=3D"color:#008">int</span><span style> i</spa=
n><span style=3D"color:#660">)</span><span style> </span><span style=3D"col=
or:#008">not</span><span style> </span><span style=3D"color:#008">override<=
/span><span style> </span><span style=3D"color:#660">{</span><span style> <=
/span><span style=3D"color:#008">return</span><span style> i</span><span st=
yle=3D"color:#660">;</span><span style> </span><span style=3D"color:#660">}=
;</span><span style><br>
=A0 =A0</span><span style=3D"color:#008">virtual</span><span style> </span>=
<span style=3D"color:#008">int</span><span style> </span><span style=3D"col=
or:#606">Helper_fn</span><span style=3D"color:#660">(</span><span style=3D"=
color:#008">int</span><span style> i</span><span style=3D"color:#660">)</sp=
an><span style> </span><span style=3D"color:#008">final</span><span style> =
</span><span style=3D"color:#660">{</span><span style><br>
=A0 =A0 =A0 prefn</span><span style=3D"color:#660">(</span><span style>i</s=
pan><span style=3D"color:#660">);</span><span style><br>=A0 =A0 =A0 </span>=
<span style=3D"color:#008">return</span><span style> postfn</span><span sty=
le=3D"color:#660">(</span><span style>fn</span><span style=3D"color:#660">(=
</span><span style>i</span><span style=3D"color:#660">),</span><span style>=
 i</span><span style=3D"color:#660">);</span><span style><br>
=A0 =A0</span><span style=3D"color:#660">}</span><span style><br>=A0 =A0</s=
pan><span style=3D"color:#800">// define prefn and postfn here</span><span =
style><br></span><span style=3D"color:#660">};</span><span style><br></span=
></div></code></div>
</div><br><br></div></div></blockquote><div><br></div><div>I have done some=
thing quite similar, make a virtual drawing function in a UI control hierar=
chy<br>final, and introduce a new one that the derived classes should overr=
ide. It would certainly<br>
have been convenient to not have to introduce a new virtual function and ha=
ve magic just<br>happen, but I&#39;m not convinced we need to support such =
cases. And on the other hand,<br>I think it was also convenient that the ma=
gic couldn&#39;t happen and the new function<br>
was introduced. C# does support such magic, though, afaik. Their &#39;new&#=
39; does the same <br>thing as that proposed &#39;not override&#39;, wherea=
s the [[new]] that was at some point part<br>of the virtual control attribu=
tes proposed for C++11 would&#39;ve meant &#39;not hiding&#39;.<br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113448745f70e204eabf3ba7--

.

On s=E1bado, 9 de novembro de 2013 14:13:26, David Krauss wrote:
> On 11/9/13 2:04 PM, Thiago Macieira wrote:
> > On s=E1bado, 9 de novembro de 2013 13:03:01, David Krauss wrote:
> >> The "not final" virt-specifier would signify a pure virtual function (=
or
> >> abstract class), but syntactically would still allow a function-body,
> >> which the "=3D 0" syntax does not
> >=20
> > It does. It just can't be in the class declaration.
>=20
> What I said is, the syntax "=3D 0" cannot be combined syntactically with =
a
> function-body. Your example has them syntactically separate in two
> declarations.

We don't need the "not final" syntax. We'd just need to change the syntax f=
or=20
the =3D 0 syntax.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 11/9/13 10:22 PM, Ville Voutilainen wrote:
> On 9 November 2013 15:30, Jean-Marc Bourguet <jm.bourguet@gmail.com> wrote:
>>> What would be the practical need for being able to say that you introduce
>>> a new virtual
>>> function that is not an override?
>>>
>> My guess is avoiding name clashes introduced by evolution (a base class
>>
> I suppose a class template with a dependent base class would further
> decrease the amount of control on the base class in such a case.

Right. That's why I used such an example.

The feature doesn't enable anything new. Like "positive" virtual and
override it only provides diagnosis.

I've never personally encountered such a conflict, but like other name
collisions, this is a recipe for confusion that you could stumble upon
by accident through composition of libraries. The potential is higher
for special member functions such as operator()().

As it is, such issues may already be diagnosed by the covariance
requirement, but that only works sometimes.

> I have done something quite similar, make a virtual drawing function in a
> UI control hierarchy
> final, and introduce a new one that the derived classes should override. It
> would certainly
> have been convenient to not have to introduce a new virtual function and
> have magic just
> happen, but I'm not convinced we need to support such cases.

I didn't propose any such change to the semantics of overriding a
"final" function. It sounds like a good thing though. Otherwise there
may be no solution to the problem that has been diagnosed.

Again, the really significant cases are when the user isn't in full
control of the name because it's an operator overload or conversion
function.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b5dbe4e2d660a04eac8d3f4
Content-Type: text/plain; charset=ISO-8859-1

On 10 November 2013 02:57, David Krauss <potswa@gmail.com> wrote:

> On 11/9/13 10:22 PM, Ville Voutilainen wrote:
>
>> On 9 November 2013 15:30, Jean-Marc Bourguet <jm.bourguet@gmail.com>
>> wrote:
>>
>>> What would be the practical need for being able to say that you introduce
>>>> a new virtual
>>>> function that is not an override?
>>>>
>>>>  My guess is avoiding name clashes introduced by evolution (a base class
>>>
>>>  I suppose a class template with a dependent base class would further
>> decrease the amount of control on the base class in such a case.
>>
>
> Right. That's why I used such an example.
>
> The feature doesn't enable anything new. Like "positive" virtual and
> override it only provides diagnosis.
>

That is not "not enabling anything new".  ;)



 I have done something quite similar, make a virtual drawing function in a
> UI control hierarchy
> final, and introduce a new one that the derived classes should override. It
> would certainly
> have been convenient to not have to introduce a new virtual function and
> have magic just
> happen, but I'm not convinced we need to support such cases.
>

I didn't propose any such change to the semantics of overriding a "final"
> function. It sounds like a good thing though. Otherwise there may be no
> solution to the problem that has been diagnosed.
>
> Again, the really significant cases are when the user isn't in full
> control of the name because it's an operator overload or conversion
> function.
>
>
>
Well, what I still don't follow is this: if you want to make a signature
final, you can do so regardless
of whether that signature comes from a base or not:
virtual whatever foo(bar) final; // works as an override, works as a new
function
but if you don't want to make a signature final, why do you care whether it
comes from
a base or not? What's the use of !override?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b5dbe4e2d660a04eac8d3f4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 November 2013 02:57, David Krauss <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 11/9/13 10:22 PM, Ville=
 Voutilainen wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
On 9 November 2013 15:30, Jean-Marc Bourguet &lt;<a href=3D"mailto:jm.bourg=
uet@gmail.com" target=3D"_blank">jm.bourguet@gmail.com</a>&gt; wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What would be the practical need for being able to say that you introduce<b=
r>
a new virtual<br>
function that is not an override?<br>
<br>
</blockquote>
My guess is avoiding name clashes introduced by evolution (a base class<br>
<br>
</blockquote></div><div class=3D"im">
I suppose a class template with a dependent base class would further<br>
decrease the amount of control on the base class in such a case.<br>
</div></blockquote>
<br>
Right. That&#39;s why I used such an example.<br>
<br>
The feature doesn&#39;t enable anything new. Like &quot;positive&quot; virt=
ual and override it only provides diagnosis.<br></blockquote><div><br></div=
><div class=3D"im">That is not &quot;not enabling anything new&quot;.=A0 ;)=
<br>
=A0<br><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I have done something quite similar, make a virtual drawing function in a<b=
r>
UI control hierarchy<br>
final, and introduce a new one that the derived classes should override. It=
<br>
would certainly<br>
have been convenient to not have to introduce a new virtual function and<br=
>
have magic just<br>
happen, but I&#39;m not convinced we need to support such cases.<br>
</blockquote>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">
I didn&#39;t propose any such change to the semantics of overriding a &quot=
;final&quot; function. It sounds like a good thing though. Otherwise there =
may be no solution to the problem that has been diagnosed.<br>
<br>
Again, the really significant cases are when the user isn&#39;t in full con=
trol of the name because it&#39;s an operator overload or conversion functi=
on.<div class=3D"HOEnZb"><div class=3D"h5"><br><br></div></div></blockquote=
>
<div><br></div><div>Well, what I still don&#39;t follow is this: if you wan=
t to make a signature final, you can do so regardless<br>of whether that si=
gnature comes from a base or not:<br></div><div>virtual whatever foo(bar) f=
inal; // works as an override, works as a new function<br>
</div><div>but if you don&#39;t want to make a signature final, why do you =
care whether it comes from<br></div><div>a base or not? What&#39;s the use =
of !override?<br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5dbe4e2d660a04eac8d3f4--

.

On 11/10/13 9:49 AM, Ville Voutilainen wrote:
> On 10 November 2013 02:57, David Krauss <potswa@gmail.com> wrote:
>
>> The feature doesn't enable anything new. Like "positive" virtual and
>> override it only provides diagnosis.
>>
> That is not "not enabling anything new".  ;)

My original proposal does not potentially alter the semantics of any
well-formed program nor make well-formed any program that would be
ill-formed without the negative virt-specifier (excepting
std::is_abstract introspection). The intent was only to make ill-formed
programs that would otherwise be "accidentally" well formed, and to
replace an existing ugly syntax (even archaic, considering what "= 0"
sets to zero) with something more regular.

> Well, what I still don't follow is this: if you want to make a
> signature final, you can do so regardless of whether that signature
> comes from a base or not: virtual whatever foo(bar) final; // works as
> an override, works as a new function but if you don't want to make a
> signature final, why do you care whether it comes from a base or not?
> What's the use of !override?

Likewise, what's the use of override? It can always be removed from a
well-formed program with no effect. Neither does the negation add a new
capability to the language, unless you allow !override to hide final as
proposed by Jean-Marc. (Which does make perfect sense.)

Override provides a means of expressing signature control. Either you do
or don't want to "allocate" a vtable entry. Accidentally allocating an
entry is the more common error, but accidentally reusing one is
essentially in the same vein. Both result from either design confusion
or template interaction.

If nothing else, it just feels strange to go through a program and mark
derived class members "override" and leave bases with "maybe override,
maybe not" when the program would clearly be broken if they were overrides.

More common errors are a higher priority, but the prevented error being
less common isn't a good counterargument to a diagnostic feature that
makes the language more regular.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e0153869226707004ead15d7b
Content-Type: text/plain; charset=ISO-8859-1

On 10 November 2013 04:25, David Krauss <potswa@gmail.com> wrote:

> On 11/10/13 9:49 AM, Ville Voutilainen wrote:
>
>> On 10 November 2013 02:57, David Krauss <potswa@gmail.com> wrote:
>>
>>  The feature doesn't enable anything new. Like "positive" virtual and
>>> override it only provides diagnosis.
>>>
>>>  That is not "not enabling anything new".  ;)
>>
>
> My original proposal does not potentially alter the semantics of any
> well-formed program nor make well-formed any program that would be
> ill-formed without the negative virt-specifier (excepting std::is_abstract
> introspection). The intent was only to make ill-formed programs that would
> otherwise be "accidentally" well formed, and to replace an existing ugly
> syntax (even archaic, considering what "= 0" sets to zero) with something
> more regular.


The question is what that "accidentally well-formed" means, and whether
it's really a problem.


>
>
>  Well, what I still don't follow is this: if you want to make a signature
>> final, you can do so regardless of whether that signature comes from a base
>> or not: virtual whatever foo(bar) final; // works as an override, works as
>> a new function but if you don't want to make a signature final, why do you
>> care whether it comes from a base or not? What's the use of !override?
>>
>
> Likewise, what's the use of override? It can always be removed from a
> well-formed program with no effect. Neither does the negation add a new
> capability to the language, unless you allow !override to hide final as
> proposed by Jean-Marc. (Which does make perfect sense.)
>

The use of override is to statically verify that you overrode an impure
virtual function correctly.
The original motivation for it stemmed from UI frameworks where a drawing
function needs
to be overridden, and failing to override correctly resulted in a
well-formed program that
doesn't draw what the user intended to draw.


>
> Override provides a means of expressing signature control. Either you do
> or don't want to "allocate" a vtable entry. Accidentally allocating an
> entry is the more common error, but accidentally reusing one is essentially
> in the same vein. Both result from either design confusion or template
> interaction.
>

Override was, as mentioned, designed for cases where the virtual function
is already
"allocated".


>
> If nothing else, it just feels strange to go through a program and mark
> derived class members "override" and leave bases with "maybe override,
> maybe not" when the program would clearly be broken if they were overrides.
>

Clearly? I don't think it's clear that a program is broken if a signature
is an override.
I have practical cases where a program is broken if an intended override is
not
an override, but thus far I have trouble finding the brokenness of the
opposite.
We did have [[new]] as a work-in-progress attribute, as mentioned, but its
motivation remains questionable. It was meant to work as "not an override,
doesn't hide". The "not an override" part doesn't seem very significant, the
"doesn't hide" is something implementations already diagnose as a
quality-of-implementation
facility.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0153869226707004ead15d7b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 10 November 2013 04:25, David Krauss <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 11/10/13 9:49 AM, Ville=
 Voutilainen wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
On 10 November 2013 02:57, David Krauss &lt;<a href=3D"mailto:potswa@gmail.=
com" target=3D"_blank">potswa@gmail.com</a>&gt; wrote:<br>
<br>
</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The feature doesn&#39;t enable anything new. Like &quot;positive&quot; virt=
ual and<br>
override it only provides diagnosis.<br>
<br>
</blockquote>
That is not &quot;not enabling anything new&quot;. =A0;)<br>
</div></blockquote>
<br>
My original proposal does not potentially alter the semantics of any well-f=
ormed program nor make well-formed any program that would be ill-formed wit=
hout the negative virt-specifier (excepting std::is_abstract introspection)=
.. The intent was only to make ill-formed programs that would otherwise be &=
quot;accidentally&quot; well formed, and to replace an existing ugly syntax=
 (even archaic, considering what &quot;=3D 0&quot; sets to zero) with somet=
hing more regular.</blockquote>
<div><br></div><div>The question is what that &quot;accidentally well-forme=
d&quot; means, and whether it&#39;s really a problem.<br>=A0<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<div class=3D"im"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Well, what I still don&#39;t follow is this: if you want to make a signatur=
e final, you can do so regardless of whether that signature comes from a ba=
se or not: virtual whatever foo(bar) final; // works as an override, works =
as a new function but if you don&#39;t want to make a signature final, why =
do you care whether it comes from a base or not? What&#39;s the use of !ove=
rride? <br>

</blockquote>
<br></div>
Likewise, what&#39;s the use of override? It can always be removed from a w=
ell-formed program with no effect. Neither does the negation add a new capa=
bility to the language, unless you allow !override to hide final as propose=
d by Jean-Marc. (Which does make perfect sense.)<br>
</blockquote><div><br></div><div>The use of override is to statically verif=
y that you overrode an impure virtual function correctly.<br></div><div>The=
 original motivation for it stemmed from UI frameworks where a drawing func=
tion needs<br>
to be overridden, and failing to override correctly resulted in a well-form=
ed program that<br>doesn&#39;t draw what the user intended to draw.<br>=A0<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">

<br>
Override provides a means of expressing signature control. Either you do or=
 don&#39;t want to &quot;allocate&quot; a vtable entry. Accidentally alloca=
ting an entry is the more common error, but accidentally reusing one is ess=
entially in the same vein. Both result from either design confusion or temp=
late interaction.<br>
</blockquote><div><br></div><div>Override was, as mentioned, designed for c=
ases where the virtual function is already<br></div><div>&quot;allocated&qu=
ot;.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
If nothing else, it just feels strange to go through a program and mark der=
ived class members &quot;override&quot; and leave bases with &quot;maybe ov=
erride, maybe not&quot; when the program would clearly be broken if they we=
re overrides.<br>
</blockquote><div><br></div><div>Clearly? I don&#39;t think it&#39;s clear =
that a program is broken if a signature is an override.<br></div><div>I hav=
e practical cases where a program is broken if an intended override is not<=
br>
an override, but thus far I have trouble finding the brokenness of the oppo=
site.<br></div><div>We did have [[new]] as a work-in-progress attribute, as=
 mentioned, but its<br>motivation remains questionable. It was meant to wor=
k as &quot;not an override,<br>
doesn&#39;t hide&quot;. The &quot;not an override&quot; part doesn&#39;t se=
em very significant, the<br></div><div>&quot;doesn&#39;t hide&quot; is some=
thing implementations already diagnose as a quality-of-implementation<br>
</div><div>facility.<br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0153869226707004ead15d7b--

.

On 11/10/13 8:00 PM, Ville Voutilainen wrote:
> On 10 November 2013 04:25, David Krauss <potswa@gmail.com> wrote:
>> Override provides a means of expressing signature control. Either you do
>> or don't want to "allocate" a vtable entry. Accidentally allocating an
>> entry is the more common error, but accidentally reusing one is essentia=
lly
>> in the same vein. Both result from either design confusion or template
>> interaction.
>>
> Override was, as mentioned, designed for cases where the virtual function
> is already
> "allocated".

Yes=85 I'm not proposing to change override, but to add a flip side to it.

>> If nothing else, it just feels strange to go through a program and mark
>> derived class members "override" and leave bases with "maybe override,
>> maybe not" when the program would clearly be broken if they were overrid=
es.
>>
> Clearly? I don't think it's clear that a program is broken if a signature
> is an override.
> I have practical cases where a program is broken if an intended override =
is
> not
> an override, but thus far I have trouble finding the brokenness of the
> opposite.

Fair point. The facility is purely opt-in so it would be up to the=20
designer whether a class must be the root base for its interface or not.=20
As mentioned, I expect that collisions most likely occur with special=20
functions such as operator()() or operator int (). Are you concerned=20
with abuse, that interfaces might adopt !override gratuitously and=20
restrict users from implementing valid designs?

I have relatively less experience with virtual functions as I usually=20
tend to avoid them. There's a backlog of proposals I've not written up,=20
particularly the one about exceptions in transaction vs.=20
std::uncaught_exception. So it might be better if someone else adopts=20
this, and I just wanted to get it out here.

> We did have [[new]] as a work-in-progress attribute, as mentioned, but it=
s
> motivation remains questionable. It was meant to work as "not an override=
,
> doesn't hide". The "not an override" part doesn't seem very significant, =
the
> "doesn't hide" is something implementations already diagnose as a
> quality-of-implementation
> facility.

The problem is that hiding a private function is still hiding. I don't=20
think that kind of facility would work without a means of preemptive=20
hiding. We do need something like that anyway. Module models tend to=20
default to hiding private members at the module boundary. How that=20
actually works, and how it should interact with virtual functions, are=20
among the many hand-wavy things about modules.

Isn't Sutter still opposed to standard attributes on the grounds that=20
they're not supposed to modify program semantics? That's why overload=20
and final aren't attributes, right?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 10 November 2013 15:55, David Krauss <potswa@gmail.com> wrote:
>
> On 11/10/13 8:00 PM, Ville Voutilainen wrote:
>>
>> On 10 November 2013 04:25, David Krauss <potswa@gmail.com> wrote:
>>>
>>> Override provides a means of expressing signature control. Either you d=
o
>>> or don't want to "allocate" a vtable entry. Accidentally allocating an
>>> entry is the more common error, but accidentally reusing one is essenti=
ally
>>> in the same vein. Both result from either design confusion or template
>>> interaction.
>>>
>> Override was, as mentioned, designed for cases where the virtual functio=
n
>> is already
>> "allocated".
>
>
> Yes=85 I'm not proposing to change override, but to add a flip side to it=
..


I understand that. I have considered such a flip side myself. I have
failed to find
sufficient motivation for it.

>
>
>
>>> If nothing else, it just feels strange to go through a program and mark
>>> derived class members "override" and leave bases with "maybe override,
>>> maybe not" when the program would clearly be broken if they were overri=
des.
>>>
>> Clearly? I don't think it's clear that a program is broken if a signatur=
e
>> is an override.
>> I have practical cases where a program is broken if an intended override=
 is
>> not
>> an override, but thus far I have trouble finding the brokenness of the
>> opposite.
>
>
> Fair point. The facility is purely opt-in so it would be up to the design=
er whether a class must be the root base for its interface or not. As menti=
oned, I expect that collisions most likely occur with special functions suc=
h as operator()() or operator int (). Are you concerned with abuse, that in=
terfaces might adopt !override gratuitously and restrict users from impleme=
nting valid designs?


No, I'm not concerned by abuse. I fail to find why it's important to
be able to say that
a class is "the root base for its interface". I don't know what design
that would express,
nor do I know what bug it would prevent. I don't see how a virtual function=
 that
happens to be an override is a "collision".


>> We did have [[new]] as a work-in-progress attribute, as mentioned, but i=
ts
>> motivation remains questionable. It was meant to work as "not an overrid=
e,
>> doesn't hide". The "not an override" part doesn't seem very significant,=
 the
>> "doesn't hide" is something implementations already diagnose as a
>> quality-of-implementation
>> facility.
> The problem is that hiding a private function is still hiding. I don't th=
ink that kind of facility would work without a means of preemptive hiding. =
We do need something like that anyway. Module models tend


I'm not sure I follow what you're saying here.

>
> to default to hiding private members at the module boundary. How that act=
ually works, and how it should interact with virtual functions, are among t=
he many hand-wavy things about modules.


It has been communicated to the SG2 people already in Kona that modules can=
not
hide private virtual functions, since those can be overridden outside modul=
es.

>
>
> Isn't Sutter still opposed to standard attributes on the grounds that the=
y're not supposed to modify program semantics? That's why overload and fina=
l aren't attributes, right?
>
>

I don't think he's opposed to attributes, he has been consistently
opposed to attributes
that have semantic effects, and yes, that's why override and final are
not attributes.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.