------=_Part_325_897842088.1444757759409
Content-Type: multipart/alternative;
 boundary="----=_Part_326_637303345.1444757759410"

------=_Part_326_637303345.1444757759410
Content-Type: text/plain; charset=UTF-8

*Motivation*
Many frameworks (Qt being one great example) require a client-defined
framework-derived class to call the framework-provided base method when
overriding a given base class virtual method.  I've encountered many bugs
that were caused by a developer forgetting/neglecting to call the (correct)
base method from their overriding implementation.

*Proposal*
Introduce a new method specifier, 'extendable', that base class authors can
use as an alternative to 'virtual' to explicitly require that overriding
methods call the base method before returning.  Any descendant overrides in
the inheritance chain from that point onward will share the same
requirement. This can then drive compile-time validation of the requirement.

*Example*
class QWidget
{
protected:
   // All overrides are required by the compiler
   // to call this base method before returning.
   extendable void keyPressEvent(QKeyEvent* keyEvent);
};

class MyWidget : public QWidget
{
protected:
    // This override inherits the "extendable" specifier, so it must call
    // QWidget::keyPressEvent() before returning.
    void keyPressEvent(QKeyEvent* keyEvent) override;
};

class MyMoreSpecificWidget : public MyWidget
{
protected:
    // This override inherits the "extendable" specifier, so it must call
    // MyWidget::keyPressEvent() before returning.
    void keyPressEvent(QKeyEvent* keyEvent) 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/.

------=_Part_326_637303345.1444757759410
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><b><font size=3D"4">Motivation</font></b><div><font size=
=3D"2">Many frameworks (Qt being one great example) require a client-define=
d framework-derived class to call the framework-provided base method when o=
verriding a given base class virtual method. =C2=A0I&#39;ve encountered man=
y bugs that were caused by a developer forgetting/neglecting to call the (c=
orrect) base method from their overriding implementation.</font></div><div>=
<font size=3D"2"><br></font></div><div><font size=3D"4"><b>Proposal</b></fo=
nt></div><div><font size=3D"2">Introduce a new method specifier, &#39;exten=
dable&#39;, that base class authors can use as an alternative to &#39;virtu=
al&#39; to explicitly require that overriding methods call the base method =
before returning. =C2=A0</font><span style=3D"font-size: small;">Any descen=
dant overrides in the inheritance chain from that point onward will share t=
he same requirement.=C2=A0</span><span style=3D"font-size: small;">This can=
 then drive compile-time validation of the requirement.</span></div><div><b=
r></div><div><div><font size=3D"4"><b>Example</b></font></div></div><div><f=
ont face=3D"courier new, monospace" size=3D"2">class QWidget</font></div><d=
iv><font face=3D"courier new, monospace" size=3D"2">{</font></div><div><spa=
n style=3D"font-family: &#39;courier new&#39;, monospace; font-size: small;=
">protected:</span><br></div><div><font face=3D"courier new, monospace" siz=
e=3D"2">=C2=A0 =C2=A0// All overrides are required by the compiler</font></=
div><div><font face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0// t=
o call this base method before returning.</font></div><div><font face=3D"co=
urier new, monospace" size=3D"2">=C2=A0 =C2=A0extendable void keyPressEvent=
(QKeyEvent* keyEvent);</font></div><div><span style=3D"font-family: &#39;co=
urier new&#39;, monospace; font-size: small;">};</span><br></div><div><font=
 face=3D"courier new, monospace" size=3D"2"><br></font></div><div><font fac=
e=3D"courier new, monospace" size=3D"2">class MyWidget : public QWidget</fo=
nt></div><div><font face=3D"courier new, monospace" size=3D"2">{</font></di=
v><div><span style=3D"font-family: &#39;courier new&#39;, monospace; font-s=
ize: small;">protected:</span><br></div><div><font face=3D"courier new, mon=
ospace" size=3D"2">=C2=A0 =C2=A0 // This override inherits the &quot;extend=
able&quot; specifier, so it must call</font></div><div><font face=3D"courie=
r new, monospace" size=3D"2">=C2=A0 =C2=A0 // QWidget::keyPressEvent() befo=
re returning.</font></div><div><span style=3D"font-family: &#39;courier new=
&#39;, monospace; font-size: small;">=C2=A0 =C2=A0 void keyPressEvent(QKeyE=
vent* keyEvent) override;</span><br></div><div><font face=3D"courier new, m=
onospace" size=3D"2">};</font></div><div><font face=3D"courier new, monospa=
ce" size=3D"2"><br></font></div><div><font face=3D"courier new, monospace" =
size=3D"2">class MyMoreSpecificWidget : public MyWidget</font></div><div><f=
ont face=3D"courier new, monospace" size=3D"2">{</font></div><div><font fac=
e=3D"courier new, monospace" size=3D"2">protected:</font></div><div><font f=
ace=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0 // This override in=
herits the &quot;extendable&quot; specifier, so it must call</font></div><d=
iv><font face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0 // MyWidg=
et::keyPressEvent() before returning.</font></div><div><font face=3D"courie=
r new, monospace" size=3D"2">=C2=A0 =C2=A0 void keyPressEvent(QKeyEvent* ke=
yEvent) override;</font></div><div><font face=3D"courier new, monospace" si=
ze=3D"2">};</font></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_326_637303345.1444757759410--
------=_Part_325_897842088.1444757759409--

.

--001a113dc818eb88de0522001173
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

El 13/10/2015 14:36, <keith.f.kelly@gmail.com> escribi=C3=B3:
>
> Motivation
> Many frameworks (Qt being one great example) require a client-defined
framework-derived class to call the framework-provided base method when
overriding a given base class virtual method.  I've encountered many bugs
that were caused by a developer forgetting/neglecting to call the (correct)
base method from their overriding implementation.

This should be solved at design time by dependency inversion (or something
like the template method design pattern).
I don't see the need for a new extension.
Or, OTOH, a non std attribute to enable a warning so base class' method is
annotated with something like "call_always_after".

>
> Proposal
> Introduce a new method specifier, 'extendable', that base class authors
can use as an alternative to 'virtual' to explicitly require that
overriding methods call the base method before returning.  Any descendant
overrides in the inheritance chain from that point onward will share the
same requirement. This can then drive compile-time validation of the
requirement.
>
> Example
> class QWidget
> {
> protected:
>    // All overrides are required by the compiler
>    // to call this base method before returning.
>    extendable void keyPressEvent(QKeyEvent* keyEvent);
> };
>
> class MyWidget : public QWidget
> {
> protected:
>     // This override inherits the "extendable" specifier, so it must call
>     // QWidget::keyPressEvent() before returning.
>     void keyPressEvent(QKeyEvent* keyEvent) override;
> };
>
> class MyMoreSpecificWidget : public MyWidget
> {
> protected:
>     // This override inherits the "extendable" specifier, so it must call
>     // MyWidget::keyPressEvent() before returning.
>     void keyPressEvent(QKeyEvent* keyEvent) 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/.

--=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/.

--001a113dc818eb88de0522001173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
El 13/10/2015 14:36, &lt;<a href=3D"mailto:keith.f.kelly@gmail.com">keith.f=
..kelly@gmail.com</a>&gt; escribi=C3=B3:<br>
&gt;<br>
&gt; Motivation<br>
&gt; Many frameworks (Qt being one great example) require a client-defined =
framework-derived class to call the framework-provided base method when ove=
rriding a given base class virtual method.=C2=A0 I&#39;ve encountered many =
bugs that were caused by a developer forgetting/neglecting to call the (cor=
rect) base method from their overriding implementation.</p>
<p dir=3D"ltr">This should be solved at design time by dependency inversion=
 (or something like the template method design pattern).<br>
I don&#39;t see the need for a new extension.<br>
Or, OTOH, a non std attribute to enable a warning so base class&#39; method=
 is annotated with something like &quot;call_always_after&quot;.<br></p>
<p dir=3D"ltr">&gt;<br>
&gt; Proposal<br>
&gt; Introduce a new method specifier, &#39;extendable&#39;, that base clas=
s authors can use as an alternative to &#39;virtual&#39; to explicitly requ=
ire that overriding methods call the base method before returning.=C2=A0 An=
y descendant overrides in the inheritance chain from that point onward will=
 share the same requirement.=C2=A0This can then drive compile-time validati=
on of the requirement.<br>
&gt;<br>
&gt; Example<br>
&gt; class QWidget<br>
&gt; {<br>
&gt; protected:<br>
&gt; =C2=A0 =C2=A0// All overrides are required by the compiler<br>
&gt; =C2=A0 =C2=A0// to call this base method before returning.<br>
&gt; =C2=A0 =C2=A0extendable void keyPressEvent(QKeyEvent* keyEvent);<br>
&gt; };<br>
&gt;<br>
&gt; class MyWidget : public QWidget<br>
&gt; {<br>
&gt; protected:<br>
&gt; =C2=A0 =C2=A0 // This override inherits the &quot;extendable&quot; spe=
cifier, so it must call<br>
&gt; =C2=A0 =C2=A0 // QWidget::keyPressEvent() before returning.<br>
&gt; =C2=A0 =C2=A0 void keyPressEvent(QKeyEvent* keyEvent) override;<br>
&gt; };<br>
&gt;<br>
&gt; class MyMoreSpecificWidget : public MyWidget<br>
&gt; {<br>
&gt; protected:<br>
&gt; =C2=A0 =C2=A0 // This override inherits the &quot;extendable&quot; spe=
cifier, so it must call<br>
&gt; =C2=A0 =C2=A0 // MyWidget::keyPressEvent() before returning.<br>
&gt; =C2=A0 =C2=A0 void keyPressEvent(QKeyEvent* keyEvent) override;<br>
&gt; };<br>
&gt;<br>
&gt; -- <br>
&gt;<br>
&gt; --- <br>
&gt; You received this message because you are subscribed to the Google Gro=
ups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-propos=
als/</a>.<br>
</p>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a113dc818eb88de0522001173--

.

--94eb2c034458935d8f05220035b6
Content-Type: text/plain; charset=UTF-8

On one hand, I think that this is one of those design situations where you
can always fix the problem with a layer of indirection:

class BaseClass {
public:
     void doTheThing(etc) { internalDoTheThing(etc); doBaseClassStuff(etc);
}
protected:
     virtual void internalDoTheThing(etc) { /* nothing */ }  // Or = 0;
};

On the other hand... this bugs from this exact problem bite us once a
month, at least. We literally had two bugs filed yesterday which were both
related to a user deriving from a base class and forgetting to call the
base version of a virtual function, despite clear documentation indicating
that this was necessary.

So - I don't think it is strictly necessary, but if it existed, we'd use it
religiously.

Chris

On Tue, Oct 13, 2015 at 10:35 AM, <keith.f.kelly@gmail.com> wrote:

> *Motivation*
> Many frameworks (Qt being one great example) require a client-defined
> framework-derived class to call the framework-provided base method when
> overriding a given base class virtual method.  I've encountered many bugs
> that were caused by a developer forgetting/neglecting to call the (correct)
> base method from their overriding implementation.
>
> *Proposal*
> Introduce a new method specifier, 'extendable', that base class authors
> can use as an alternative to 'virtual' to explicitly require that
> overriding methods call the base method before returning.  Any descendant
> overrides in the inheritance chain from that point onward will share the
> same requirement. This can then drive compile-time validation of the
> requirement.
>
> *Example*
> class QWidget
> {
> protected:
>    // All overrides are required by the compiler
>    // to call this base method before returning.
>    extendable void keyPressEvent(QKeyEvent* keyEvent);
> };
>
> class MyWidget : public QWidget
> {
> protected:
>     // This override inherits the "extendable" specifier, so it must call
>     // QWidget::keyPressEvent() before returning.
>     void keyPressEvent(QKeyEvent* keyEvent) override;
> };
>
> class MyMoreSpecificWidget : public MyWidget
> {
> protected:
>     // This override inherits the "extendable" specifier, so it must call
>     // MyWidget::keyPressEvent() before returning.
>     void keyPressEvent(QKeyEvent* keyEvent) 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/.
>

--

---
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/.

--94eb2c034458935d8f05220035b6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On one hand, I think that this is one of those design situ=
ations where you can always fix the problem with a layer of indirection:<di=
v><br></div><div><font face=3D"monospace, monospace">class BaseClass {</fon=
t></div><div><font face=3D"monospace, monospace">public:</font></div><div><=
font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0void doTheThing(etc)=
 { internalDoTheThing(etc); doBaseClassStuff(etc); }</font></div><div><font=
 face=3D"monospace, monospace">protected:</font></div><div><font face=3D"mo=
nospace, monospace">=C2=A0 =C2=A0 =C2=A0virtual void internalDoTheThing(etc=
) { /* nothing */ } =C2=A0// Or =3D 0;</font></div><div><font face=3D"monos=
pace, monospace">};</font></div><div><br></div><div>On the other hand... th=
is bugs from this exact problem bite us once a month, at least. We literall=
y had two bugs filed yesterday which were both related to a user deriving f=
rom a base class and forgetting to call the base version of a virtual funct=
ion, despite clear documentation indicating that this was necessary.</div><=
div><br></div><div>So - I don&#39;t think it is strictly necessary, but if =
it existed, we&#39;d use it religiously.</div><div><br></div><div>Chris</di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, O=
ct 13, 2015 at 10:35 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:keith.f.k=
elly@gmail.com" target=3D"_blank">keith.f.kelly@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b><font size=3D"4"=
>Motivation</font></b><div><font size=3D"2">Many frameworks (Qt being one g=
reat example) require a client-defined framework-derived class to call the =
framework-provided base method when overriding a given base class virtual m=
ethod.=C2=A0 I&#39;ve encountered many bugs that were caused by a developer=
 forgetting/neglecting to call the (correct) base method from their overrid=
ing implementation.</font></div><div><font size=3D"2"><br></font></div><div=
><font size=3D"4"><b>Proposal</b></font></div><div><font size=3D"2">Introdu=
ce a new method specifier, &#39;extendable&#39;, that base class authors ca=
n use as an alternative to &#39;virtual&#39; to explicitly require that ove=
rriding methods call the base method before returning. =C2=A0</font><span s=
tyle=3D"font-size:small">Any descendant overrides in the inheritance chain =
from that point onward will share the same requirement.=C2=A0</span><span s=
tyle=3D"font-size:small">This can then drive compile-time validation of the=
 requirement.</span></div><div><br></div><div><div><font size=3D"4"><b>Exam=
ple</b></font></div></div><div><font face=3D"courier new, monospace" size=
=3D"2">class QWidget</font></div><div><font face=3D"courier new, monospace"=
 size=3D"2">{</font></div><div><span style=3D"font-family:&#39;courier new&=
#39;,monospace;font-size:small">protected:</span><br></div><div><font face=
=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0// All overrides are re=
quired by the compiler</font></div><div><font face=3D"courier new, monospac=
e" size=3D"2">=C2=A0 =C2=A0// to call this base method before returning.</f=
ont></div><div><font face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=
=A0extendable void keyPressEvent(QKeyEvent* keyEvent);</font></div><div><sp=
an style=3D"font-family:&#39;courier new&#39;,monospace;font-size:small">};=
</span><br></div><div><font face=3D"courier new, monospace" size=3D"2"><br>=
</font></div><div><font face=3D"courier new, monospace" size=3D"2">class My=
Widget : public QWidget</font></div><div><font face=3D"courier new, monospa=
ce" size=3D"2">{</font></div><div><span style=3D"font-family:&#39;courier n=
ew&#39;,monospace;font-size:small">protected:</span><br></div><div><font fa=
ce=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0 // This override inh=
erits the &quot;extendable&quot; specifier, so it must call</font></div><di=
v><font face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0 // QWidget=
::keyPressEvent() before returning.</font></div><div><span style=3D"font-fa=
mily:&#39;courier new&#39;,monospace;font-size:small">=C2=A0 =C2=A0 void ke=
yPressEvent(QKeyEvent* keyEvent) override;</span><br></div><div><font face=
=3D"courier new, monospace" size=3D"2">};</font></div><div><font face=3D"co=
urier new, monospace" size=3D"2"><br></font></div><div><font face=3D"courie=
r new, monospace" size=3D"2">class MyMoreSpecificWidget : public MyWidget</=
font></div><div><font face=3D"courier new, monospace" size=3D"2">{</font></=
div><div><font face=3D"courier new, monospace" size=3D"2">protected:</font>=
</div><div><font face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0 /=
/ This override inherits the &quot;extendable&quot; specifier, so it must c=
all</font></div><div><font face=3D"courier new, monospace" size=3D"2">=C2=
=A0 =C2=A0 // MyWidget::keyPressEvent() before returning.</font></div><div>=
<font face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0 void keyPres=
sEvent(QKeyEvent* keyEvent) override;</font></div><div><font face=3D"courie=
r new, monospace" size=3D"2">};</font></div></div><span class=3D"HOEnZb"><f=
ont color=3D"#888888">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--94eb2c034458935d8f05220035b6--

.

--047d7b2e489aa3e02e0522008e11
Content-Type: text/plain; charset=UTF-8

Are you saying that the token sequence "base::foo( ... );" must appear in
the body of the function?

Does if(false) base::foo(); properly extend an extendable function?

I agree that dependency inversion usually solves these issues, but I can
imagine cases where that's not a good way to solve the problem.

On Tue, Oct 13, 2015 at 12:59 PM, Christopher Horvath <blackencino@gmail.com
> wrote:

> On one hand, I think that this is one of those design situations where you
> can always fix the problem with a layer of indirection:
>
> class BaseClass {
> public:
>      void doTheThing(etc) { internalDoTheThing(etc);
> doBaseClassStuff(etc); }
> protected:
>      virtual void internalDoTheThing(etc) { /* nothing */ }  // Or = 0;
> };
>
> On the other hand... this bugs from this exact problem bite us once a
> month, at least. We literally had two bugs filed yesterday which were both
> related to a user deriving from a base class and forgetting to call the
> base version of a virtual function, despite clear documentation indicating
> that this was necessary.
>
> So - I don't think it is strictly necessary, but if it existed, we'd use
> it religiously.
>
> Chris
>
> On Tue, Oct 13, 2015 at 10:35 AM, <keith.f.kelly@gmail.com> wrote:
>
>> *Motivation*
>> Many frameworks (Qt being one great example) require a client-defined
>> framework-derived class to call the framework-provided base method when
>> overriding a given base class virtual method.  I've encountered many bugs
>> that were caused by a developer forgetting/neglecting to call the (correct)
>> base method from their overriding implementation.
>>
>> *Proposal*
>> Introduce a new method specifier, 'extendable', that base class authors
>> can use as an alternative to 'virtual' to explicitly require that
>> overriding methods call the base method before returning.  Any
>> descendant overrides in the inheritance chain from that point onward will
>> share the same requirement. This can then drive compile-time validation
>> of the requirement.
>>
>> *Example*
>> class QWidget
>> {
>> protected:
>>    // All overrides are required by the compiler
>>    // to call this base method before returning.
>>    extendable void keyPressEvent(QKeyEvent* keyEvent);
>> };
>>
>> class MyWidget : public QWidget
>> {
>> protected:
>>     // This override inherits the "extendable" specifier, so it must call
>>     // QWidget::keyPressEvent() before returning.
>>     void keyPressEvent(QKeyEvent* keyEvent) override;
>> };
>>
>> class MyMoreSpecificWidget : public MyWidget
>> {
>> protected:
>>     // This override inherits the "extendable" specifier, so it must call
>>     // MyWidget::keyPressEvent() before returning.
>>     void keyPressEvent(QKeyEvent* keyEvent) 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/.
>>
>
> --
>
> ---
> 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/.
>

--

---
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/.

--047d7b2e489aa3e02e0522008e11
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Are you saying that the token sequence &quot;base::fo=
o( ... );&quot; must appear in the body of the function?<br></div><div><br>=
</div><div>Does if(false) base::foo(); properly extend an extendable functi=
on?</div><div><br></div><div>I agree that dependency inversion usually solv=
es these issues, but I can imagine cases where that&#39;s not a good way to=
 solve the problem.</div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">On Tue, Oct 13, 2015 at 12:59 PM, Christopher Horvath <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:blackencino@gmail.com" target=3D"_blank">b=
lackencino@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">On one hand, I think that this is one of those design si=
tuations where you can always fix the problem with a layer of indirection:<=
div><br></div><div><font face=3D"monospace, monospace">class BaseClass {</f=
ont></div><div><font face=3D"monospace, monospace">public:</font></div><div=
><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=A0void doTheThing(et=
c) { internalDoTheThing(etc); doBaseClassStuff(etc); }</font></div><div><fo=
nt face=3D"monospace, monospace">protected:</font></div><div><font face=3D"=
monospace, monospace">=C2=A0 =C2=A0 =C2=A0virtual void internalDoTheThing(e=
tc) { /* nothing */ } =C2=A0// Or =3D 0;</font></div><div><font face=3D"mon=
ospace, monospace">};</font></div><div><br></div><div>On the other hand... =
this bugs from this exact problem bite us once a month, at least. We litera=
lly had two bugs filed yesterday which were both related to a user deriving=
 from a base class and forgetting to call the base version of a virtual fun=
ction, despite clear documentation indicating that this was necessary.</div=
><div><br></div><div>So - I don&#39;t think it is strictly necessary, but i=
f it existed, we&#39;d use it religiously.</div><div><br></div><div>Chris</=
div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Tue, Oct 13, 2015 at 10:35 AM,  <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:keith.f.kelly@gmail.com" target=3D"_blank"=
>keith.f.kelly@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><b><font size=3D"4">Motivation</font></b><div><font =
size=3D"2">Many frameworks (Qt being one great example) require a client-de=
fined framework-derived class to call the framework-provided base method wh=
en overriding a given base class virtual method.=C2=A0 I&#39;ve encountered=
 many bugs that were caused by a developer forgetting/neglecting to call th=
e (correct) base method from their overriding implementation.</font></div><=
div><font size=3D"2"><br></font></div><div><font size=3D"4"><b>Proposal</b>=
</font></div><div><font size=3D"2">Introduce a new method specifier, &#39;e=
xtendable&#39;, that base class authors can use as an alternative to &#39;v=
irtual&#39; to explicitly require that overriding methods call the base met=
hod before returning. =C2=A0</font><span style=3D"font-size:small">Any desc=
endant overrides in the inheritance chain from that point onward will share=
 the same requirement.=C2=A0</span><span style=3D"font-size:small">This can=
 then drive compile-time validation of the requirement.</span></div><div><b=
r></div><div><div><font size=3D"4"><b>Example</b></font></div></div><div><f=
ont face=3D"courier new, monospace" size=3D"2">class QWidget</font></div><d=
iv><font face=3D"courier new, monospace" size=3D"2">{</font></div><div><spa=
n style=3D"font-family:&#39;courier new&#39;,monospace;font-size:small">pro=
tected:</span><br></div><div><font face=3D"courier new, monospace" size=3D"=
2">=C2=A0 =C2=A0// All overrides are required by the compiler</font></div><=
div><font face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0// to cal=
l this base method before returning.</font></div><div><font face=3D"courier=
 new, monospace" size=3D"2">=C2=A0 =C2=A0extendable void keyPressEvent(QKey=
Event* keyEvent);</font></div><div><span style=3D"font-family:&#39;courier =
new&#39;,monospace;font-size:small">};</span><br></div><div><font face=3D"c=
ourier new, monospace" size=3D"2"><br></font></div><div><font face=3D"couri=
er new, monospace" size=3D"2">class MyWidget : public QWidget</font></div><=
div><font face=3D"courier new, monospace" size=3D"2">{</font></div><div><sp=
an style=3D"font-family:&#39;courier new&#39;,monospace;font-size:small">pr=
otected:</span><br></div><div><font face=3D"courier new, monospace" size=3D=
"2">=C2=A0 =C2=A0 // This override inherits the &quot;extendable&quot; spec=
ifier, so it must call</font></div><div><font face=3D"courier new, monospac=
e" size=3D"2">=C2=A0 =C2=A0 // QWidget::keyPressEvent() before returning.</=
font></div><div><span style=3D"font-family:&#39;courier new&#39;,monospace;=
font-size:small">=C2=A0 =C2=A0 void keyPressEvent(QKeyEvent* keyEvent) over=
ride;</span><br></div><div><font face=3D"courier new, monospace" size=3D"2"=
>};</font></div><div><font face=3D"courier new, monospace" size=3D"2"><br><=
/font></div><div><font face=3D"courier new, monospace" size=3D"2">class MyM=
oreSpecificWidget : public MyWidget</font></div><div><font face=3D"courier =
new, monospace" size=3D"2">{</font></div><div><font face=3D"courier new, mo=
nospace" size=3D"2">protected:</font></div><div><font face=3D"courier new, =
monospace" size=3D"2">=C2=A0 =C2=A0 // This override inherits the &quot;ext=
endable&quot; specifier, so it must call</font></div><div><font face=3D"cou=
rier new, monospace" size=3D"2">=C2=A0 =C2=A0 // MyWidget::keyPressEvent() =
before returning.</font></div><div><font face=3D"courier new, monospace" si=
ze=3D"2">=C2=A0 =C2=A0 void keyPressEvent(QKeyEvent* keyEvent) override;</f=
ont></div><div><font face=3D"courier new, monospace" size=3D"2">};</font></=
div></div><span><font color=3D"#888888">

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--047d7b2e489aa3e02e0522008e11--

.

On 2015-10-13 13:35, keith.f.kelly@gmail.com wrote:
> *Motivation*
> Many frameworks (Qt being one great example) require a client-defined=20
> framework-derived class to call the framework-provided base method when=
=20
> overriding a given base class virtual method.  I've encountered many bugs=
=20
> that were caused by a developer forgetting/neglecting to call the (correc=
t)=20
> base method from their overriding implementation.
>=20
> *Proposal*
> Introduce a new method specifier, 'extendable', that base class authors c=
an=20
> use as an alternative to 'virtual' to explicitly require that overriding=
=20
> methods call the base method before returning.  Any descendant overrides =
in=20
> the inheritance chain from that point onward will share the same=20
> requirement. This can then drive compile-time validation of the requireme=
nt.
>=20
> *Example*
> class QWidget
> {
> protected:
>    // All overrides are required by the compiler
>    // to call this base method before returning.
>    extendable void keyPressEvent(QKeyEvent* keyEvent);
> };

Oy, please, no... I might *want* to swallow the event and not propagate
it. That might even be the whole reason I overrode the method!

I suspect in general you'd run into this sort of problem; your proposal
removes quite a bit of flexibility from users. (Which anyway, as noted,
can already be done by having the virtual method be a no-op and having
the real method call the virtual, then perform the base class function.)

This might make sense as an attribute to encourage compilers to *warn*
if you forget to call the base class method. I don't think I'd be in
favor of allowing a class to *force* its derived classes to call its
method when overriding.

Another reason I'd prefer not to legislate is for cases like:

  void foo(...) // overridden virtual
  {
    if (...)
    {
      Base::foo(...);
      ... do additional stuff here ...
      return;
    }

    ... lots more logic ...
    Base::foo(...);
  }

It's not so hard=C2=B9 for many modern compilers to emit a warning if some
code path fails to call the base method with few false positives or
false negatives. It's quite another thing to *mandate* that *any*
conforming compiler *must* emit errors for such cases, which presumably
means it *must* have zero FP's, and really, really *ought* to have zero
FN's (a false negative would still be a compiler bug, but at least it
wouldn't prevent valid code from compiling).

Keep in mind that even the above is a "simple" case. You can also run
into e.g. handling values of an enum with no default case, where the
base method is only called within the switch. Is that an error? Many
(including myself) will argue that it is not.

(=C2=B9 Mind, determining possible code paths *is* hard, but compilers
already do this, e.g. to find non-void functions that fail to return a
value, or for dead code elimination. So adding onto this existing logic
for compilers that already have such is presumably not unreasonably
difficult. Mandating that a conforming compiler be able to do this, on
the other hand...)

--=20
Matthew

--=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 2015-10-13 14:24, Brent Friedman wrote:
> Are you saying that the token sequence "base::foo( ... );" must appear in
> the body of the function?

I'm sure that's *not* what Keith intended. I assume he intended either
that calling the base method is the *last* thing that happens before the
function call returns (which horribly, horribly limits overriding
methods), or that no reasonable code path fails to call the base method
(which is very hard to enforce; see my other post). That being the case...

> Does if(false) base::foo(); properly extend an extendable function?

....no. This satisfies neither of the above requirements. (OTOH, I'd find
your approach - simply that a call to the base method exists *somewhere*
in the body of the overriding method, even if it is trivially
unreachable - much more palatable to enforce strictly, as it's trivial
to work around when needed. However, that seems more brittle and prone
to being misused than using an attribute to warn about possible code
paths that fail to call the base method. The latter, presumably, would
have a simple way to suppress the warning, ideally for specific code
paths, that would be less prone to unintentional misuse.)

--
Matthew

--

---
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/.

.

------=_Part_7590_1577237449.1444765272561
Content-Type: multipart/alternative;
 boundary="----=_Part_7591_1914532018.1444765272561"

------=_Part_7591_1914532018.1444765272561
Content-Type: text/plain; charset=UTF-8

Exactly -- there's idealistic design patterns, and then there's practical
reality for large existing code bases.  This proposal is specifically
motivated by a desire to surface and prevent bugs in the latter.

--

---
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/.

------=_Part_7591_1914532018.1444765272561
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Exactly -- there&#39;s idealistic design patterns, and the=
n there&#39;s practical reality for large existing code bases. =C2=A0This p=
roposal is specifically motivated by a desire to surface and prevent bugs i=
n the latter.</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7591_1914532018.1444765272561--
------=_Part_7590_1577237449.1444765272561--

.

------=_Part_2992_516867287.1444765320923
Content-Type: multipart/alternative;
 boundary="----=_Part_2993_979329154.1444765320923"

------=_Part_2993_979329154.1444765320923
Content-Type: text/plain; charset=UTF-8

I'm saying that every possible return path from the derived method must
call base::foo().

--

---
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/.

------=_Part_2993_979329154.1444765320923
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I&#39;m saying that every possible return path from the derived method must call base::foo().</div>

<p></p>

-- <br />
<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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_2993_979329154.1444765320923--
------=_Part_2992_516867287.1444765320923--

.

On 13 October 2015 at 22:42,  <keith.f.kelly@gmail.com> wrote:
> I'm saying that every possible return path from the derived method must call
> base::foo().

A compiler cannot statically prove that to be the case.

--

---
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/.

.

------=_Part_2933_1896112491.1444766221281
Content-Type: multipart/alternative;
 boundary="----=_Part_2934_1302206695.1444766221281"

------=_Part_2934_1302206695.1444766221281
Content-Type: text/plain; charset=UTF-8

Why not?  It can already prove that not every path returns a value; isn't
that solving the same problem?

On Tuesday, October 13, 2015 at 12:49:00 PM UTC-7, Ville Voutilainen wrote:
>
> On 13 October 2015 at 22:42,  <keith....@gmail.com <javascript:>> wrote:
> > I'm saying that every possible return path from the derived method must
> call
> > base::foo().
>
> A compiler cannot statically prove that to be the case.
>

--

---
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/.

------=_Part_2934_1302206695.1444766221281
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Why not? =C2=A0It can already prove that not every path re=
turns a value; isn&#39;t that solving the same problem?<br><br>On Tuesday, =
October 13, 2015 at 12:49:00 PM UTC-7, Ville Voutilainen wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">On 13 October 2015 at 22:42, =C2=A0&lt;<a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"P-rJS55bDgA=
J" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return=
 true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">keith...=
..@gmail.com</a>&gt; wrote:
<br>&gt; I&#39;m saying that every possible return path from the derived me=
thod must call
<br>&gt; base::foo().
<br>
<br>A compiler cannot statically prove that to be the case.
<br></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2934_1302206695.1444766221281--
------=_Part_2933_1896112491.1444766221281--

.

------=_Part_2922_335931527.1444766328773
Content-Type: multipart/alternative;
 boundary="----=_Part_2923_1408302559.1444766328773"

------=_Part_2923_1408302559.1444766328773
Content-Type: text/plain; charset=UTF-8

To clarify, I'm not suggesting the compiler prove that every return path
*results* in foo::bar() having been called indirectly by way of some other
function call.  I'm suggesting the compiler prove that a literal direct
call to foo::bar() appears in execution flow before every possible return
path from the function.

On Tuesday, October 13, 2015 at 12:57:01 PM UTC-7, keith....@gmail.com
wrote:
>
> Why not?  It can already prove that not every path returns a value; isn't
> that solving the same problem?
>
> On Tuesday, October 13, 2015 at 12:49:00 PM UTC-7, Ville Voutilainen wrote:
>>
>> On 13 October 2015 at 22:42,  <keith....@gmail.com> wrote:
>> > I'm saying that every possible return path from the derived method must
>> call
>> > base::foo().
>>
>> A compiler cannot statically prove that to be the case.
>>
>

--

---
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/.

------=_Part_2923_1408302559.1444766328773
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">To clarify, I&#39;m not suggesting the compiler prove that=
 every return path *results* in foo::bar() having been called indirectly by=
 way of some other function call. =C2=A0I&#39;m suggesting the compiler pro=
ve that a literal direct call to foo::bar() appears in execution flow befor=
e every possible return path from the function.<br><br>On Tuesday, October =
13, 2015 at 12:57:01 PM UTC-7, keith....@gmail.com wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Why not? =C2=A0It can already =
prove that not every path returns a value; isn&#39;t that solving the same =
problem?<br><br>On Tuesday, October 13, 2015 at 12:49:00 PM UTC-7, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 13 October 2015 =
at 22:42, =C2=A0&lt;<a rel=3D"nofollow">keith....@gmail.com</a>&gt; wrote:
<br>&gt; I&#39;m saying that every possible return path from the derived me=
thod must call
<br>&gt; base::foo().
<br>
<br>A compiler cannot statically prove that to be the case.
<br></blockquote></div></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_2923_1408302559.1444766328773--
------=_Part_2922_335931527.1444766328773--

.

------=_Part_3008_627659826.1444766775836
Content-Type: multipart/alternative;
 boundary="----=_Part_3009_1374242080.1444766775836"

------=_Part_3009_1374242080.1444766775836
Content-Type: text/plain; charset=UTF-8

1) Yes, but not just anywhere. It must appear exactly once along each
execution path that leads to a return from the function.

2) No, because base::foo() won't actually get executed.

On Tuesday, October 13, 2015 at 11:24:35 AM UTC-7, Brent Friedman wrote:
>
> Are you saying that the token sequence "base::foo( ... );" must appear in
> the body of the function?
>
> Does if(false) base::foo(); properly extend an extendable function?
>
> I agree that dependency inversion usually solves these issues, but I can
> imagine cases where that's not a good way to solve the problem.
>
> On Tue, Oct 13, 2015 at 12:59 PM, Christopher Horvath <black...@gmail.com
> <javascript:>> wrote:
>
>> On one hand, I think that this is one of those design situations where
>> you can always fix the problem with a layer of indirection:
>>
>> class BaseClass {
>> public:
>>      void doTheThing(etc) { internalDoTheThing(etc);
>> doBaseClassStuff(etc); }
>> protected:
>>      virtual void internalDoTheThing(etc) { /* nothing */ }  // Or = 0;
>> };
>>
>> On the other hand... this bugs from this exact problem bite us once a
>> month, at least. We literally had two bugs filed yesterday which were both
>> related to a user deriving from a base class and forgetting to call the
>> base version of a virtual function, despite clear documentation indicating
>> that this was necessary.
>>
>> So - I don't think it is strictly necessary, but if it existed, we'd use
>> it religiously.
>>
>> Chris
>>
>> On Tue, Oct 13, 2015 at 10:35 AM, <keith....@gmail.com <javascript:>>
>> wrote:
>>
>>> *Motivation*
>>> Many frameworks (Qt being one great example) require a client-defined
>>> framework-derived class to call the framework-provided base method when
>>> overriding a given base class virtual method.  I've encountered many bugs
>>> that were caused by a developer forgetting/neglecting to call the (correct)
>>> base method from their overriding implementation.
>>>
>>> *Proposal*
>>> Introduce a new method specifier, 'extendable', that base class authors
>>> can use as an alternative to 'virtual' to explicitly require that
>>> overriding methods call the base method before returning.  Any
>>> descendant overrides in the inheritance chain from that point onward will
>>> share the same requirement. This can then drive compile-time validation
>>> of the requirement.
>>>
>>> *Example*
>>> class QWidget
>>> {
>>> protected:
>>>    // All overrides are required by the compiler
>>>    // to call this base method before returning.
>>>    extendable void keyPressEvent(QKeyEvent* keyEvent);
>>> };
>>>
>>> class MyWidget : public QWidget
>>> {
>>> protected:
>>>     // This override inherits the "extendable" specifier, so it must call
>>>     // QWidget::keyPressEvent() before returning.
>>>     void keyPressEvent(QKeyEvent* keyEvent) override;
>>> };
>>>
>>> class MyMoreSpecificWidget : public MyWidget
>>> {
>>> protected:
>>>     // This override inherits the "extendable" specifier, so it must call
>>>     // MyWidget::keyPressEvent() before returning.
>>>     void keyPressEvent(QKeyEvent* keyEvent) 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-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>> --
>>
>> ---
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
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/.

------=_Part_3009_1374242080.1444766775836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">1) Yes, but not just anywhere. It must appear exactly once=
 along each execution path that leads to a return from the function.<div><b=
r><div>2) No, because base::foo() won&#39;t actually get executed.</div><di=
v><br>On Tuesday, October 13, 2015 at 11:24:35 AM UTC-7, Brent Friedman wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Are y=
ou saying that the token sequence &quot;base::foo( ... );&quot; must appear=
 in the body of the function?<br></div><div><br></div><div>Does if(false) b=
ase::foo(); properly extend an extendable function?</div><div><br></div><di=
v>I agree that dependency inversion usually solves these issues, but I can =
imagine cases where that&#39;s not a good way to solve the problem.</div></=
div><div><br><div class=3D"gmail_quote">On Tue, Oct 13, 2015 at 12:59 PM, C=
hristopher Horvath <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"PVvB5wJXDgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">black...@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On one hand, I think t=
hat this is one of those design situations where you can always fix the pro=
blem with a layer of indirection:<div><br></div><div><font face=3D"monospac=
e, monospace">class BaseClass {</font></div><div><font face=3D"monospace, m=
onospace">public:</font></div><div><font face=3D"monospace, monospace">=C2=
=A0 =C2=A0 =C2=A0void doTheThing(etc) { internalDoTheThing(etc); doBaseClas=
sStuff(etc); }</font></div><div><font face=3D"monospace, monospace">protect=
ed:</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =C2=
=A0virtual void internalDoTheThing(etc) { /* nothing */ } =C2=A0// Or =3D 0=
;</font></div><div><font face=3D"monospace, monospace">};</font></div><div>=
<br></div><div>On the other hand... this bugs from this exact problem bite =
us once a month, at least. We literally had two bugs filed yesterday which =
were both related to a user deriving from a base class and forgetting to ca=
ll the base version of a virtual function, despite clear documentation indi=
cating that this was necessary.</div><div><br></div><div>So - I don&#39;t t=
hink it is strictly necessary, but if it existed, we&#39;d use it religious=
ly.</div><div><br></div><div>Chris</div></div><div><div><div><br><div class=
=3D"gmail_quote">On Tue, Oct 13, 2015 at 10:35 AM,  <span dir=3D"ltr">&lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PVvB5wJXD=
gAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">keith.=
....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><b><font size=3D"4">Motivation</font></b><div><font size=3D"2">=
Many frameworks (Qt being one great example) require a client-defined frame=
work-derived class to call the framework-provided base method when overridi=
ng a given base class virtual method.=C2=A0 I&#39;ve encountered many bugs =
that were caused by a developer forgetting/neglecting to call the (correct)=
 base method from their overriding implementation.</font></div><div><font s=
ize=3D"2"><br></font></div><div><font size=3D"4"><b>Proposal</b></font></di=
v><div><font size=3D"2">Introduce a new method specifier, &#39;extendable&#=
39;, that base class authors can use as an alternative to &#39;virtual&#39;=
 to explicitly require that overriding methods call the base method before =
returning. =C2=A0</font><span style=3D"font-size:small">Any descendant over=
rides in the inheritance chain from that point onward will share the same r=
equirement.=C2=A0</span><span style=3D"font-size:small">This can then drive=
 compile-time validation of the requirement.</span></div><div><br></div><di=
v><div><font size=3D"4"><b>Example</b></font></div></div><div><font face=3D=
"courier new, monospace" size=3D"2">class QWidget</font></div><div><font fa=
ce=3D"courier new, monospace" size=3D"2">{</font></div><div><span style=3D"=
font-family:&#39;courier new&#39;,monospace;font-size:small">protected:</sp=
an><br></div><div><font face=3D"courier new, monospace" size=3D"2">=C2=A0 =
=C2=A0// All overrides are required by the compiler</font></div><div><font =
face=3D"courier new, monospace" size=3D"2">=C2=A0 =C2=A0// to call this bas=
e method before returning.</font></div><div><font face=3D"courier new, mono=
space" size=3D"2">=C2=A0 =C2=A0extendable void keyPressEvent(QKeyEvent* key=
Event);</font></div><div><span style=3D"font-family:&#39;courier new&#39;,m=
onospace;font-size:small">};</span><br></div><div><font face=3D"courier new=
, monospace" size=3D"2"><br></font></div><div><font face=3D"courier new, mo=
nospace" size=3D"2">class MyWidget : public QWidget</font></div><div><font =
face=3D"courier new, monospace" size=3D"2">{</font></div><div><span style=
=3D"font-family:&#39;courier new&#39;,monospace;font-size:small">protected:=
</span><br></div><div><font face=3D"courier new, monospace" size=3D"2">=C2=
=A0 =C2=A0 // This override inherits the &quot;extendable&quot; specifier, =
so it must call</font></div><div><font face=3D"courier new, monospace" size=
=3D"2">=C2=A0 =C2=A0 // QWidget::keyPressEvent() before returning.</font></=
div><div><span style=3D"font-family:&#39;courier new&#39;,monospace;font-si=
ze:small">=C2=A0 =C2=A0 void keyPressEvent(QKeyEvent* keyEvent) override;</=
span><br></div><div><font face=3D"courier new, monospace" size=3D"2">};</fo=
nt></div><div><font face=3D"courier new, monospace" size=3D"2"><br></font><=
/div><div><font face=3D"courier new, monospace" size=3D"2">class MyMoreSpec=
ificWidget : public MyWidget</font></div><div><font face=3D"courier new, mo=
nospace" size=3D"2">{</font></div><div><font face=3D"courier new, monospace=
" size=3D"2">protected:</font></div><div><font face=3D"courier new, monospa=
ce" size=3D"2">=C2=A0 =C2=A0 // This override inherits the &quot;extendable=
&quot; specifier, so it must call</font></div><div><font face=3D"courier ne=
w, monospace" size=3D"2">=C2=A0 =C2=A0 // MyWidget::keyPressEvent() before =
returning.</font></div><div><font face=3D"courier new, monospace" size=3D"2=
">=C2=A0 =C2=A0 void keyPressEvent(QKeyEvent* keyEvent) override;</font></d=
iv><div><font face=3D"courier new, monospace" size=3D"2">};</font></div></d=
iv><span><font color=3D"#888888">

<p></p>

-- <br>
<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 <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
PVvB5wJXDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"PVvB5wJXDgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</font></span></blockquote></div><br></div>

<p></p>

-- <br>
<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 <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
PVvB5wJXDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"PVvB5wJXDgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3009_1374242080.1444766775836--
------=_Part_3008_627659826.1444766775836--

.

Please don't top-post; it makes it harder to follow the conversation.

On 2015-10-13 15:57, keith.f.kelly@gmail.com wrote:
> On Tuesday, October 13, 2015 at 12:49:00 PM UTC-7, Ville Voutilainen wrote:
>> On 13 October 2015 at 22:42,  <keith....@gmail.com <javascript:>> wrote:
>>> I'm saying that every possible return path from the derived method must
>>> call base::foo().
>>
>> A compiler cannot statically prove that to be the case.
>
> Why not?  It can already prove that not every path returns a value; isn't
> that solving the same problem?

No, it can't. *Some* compilers can attempt to solve this problem with a
low rate of false positives, and even that is *hard*. Proposing to
require that *every* conforming compiler must do so *perfectly* is not
likely to go over well.

Please read the other replies I posted to this thread which already
discussed this exact issue.

--
Matthew

--

---
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/.

.

------=_Part_7970_1166140983.1444769807211
Content-Type: multipart/alternative;
 boundary="----=_Part_7971_1490433062.1444769807211"

------=_Part_7971_1490433062.1444769807211
Content-Type: text/plain; charset=UTF-8

Sorry, but I don't know what you mean by "top post".

On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>
> Please don't top-post; it makes it harder to follow the conversation.
>

--

---
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/.

------=_Part_7971_1490433062.1444769807211
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry, but I don&#39;t know what you mean by &quot;top pos=
t&quot;.<br><br>On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Please don&#39;t =
top-post; it makes it harder to follow the conversation.
<br></blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7971_1490433062.1444769807211--
------=_Part_7970_1166140983.1444769807211--

.

------=_Part_3757_576094496.1444770081835
Content-Type: multipart/alternative;
 boundary="----=_Part_3758_610848860.1444770081835"

------=_Part_3758_610848860.1444770081835
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>
> No, it can't. *Some* compilers can attempt to solve this problem with a
> low rate of false positives, and even that is *hard*. Proposing to
> require that *every* conforming compiler must do so *perfectly* is not
> likely to go over well.
>

Every C++ compiler I've ever encountered will produce an error if you write
a function like this, because not every execution path returns a value, and
the function signatures requires that the function return a value. Are you
saying not all compilers will error on this kind of programmer oversight?
I'm not familiar with compiler design but it would seem to me to be a
trivial thing to prove that every way of returning from this function
actually returned an int.

int Foo(int valueIn)
{
    if (valueIn == 5) return 15;
    // Compilation error because for all other values of valueIn
    // there is no int returned.
}

--

---
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/.

------=_Part_3758_610848860.1444770081835
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">No, it can&#39;t=
.. *Some* compilers can attempt to solve this problem with a
<br>low rate of false positives, and even that is *hard*. Proposing to
<br>require that *every* conforming compiler must do so *perfectly* is not
<br>likely to go over well.
<br></blockquote><div>=C2=A0</div><div>Every C++ compiler I&#39;ve ever enc=
ountered will produce an error if you write a function like this, because n=
ot every execution path returns a value, and the function signatures requir=
es that the function return a value. Are you saying not all compilers will =
error on this kind of programmer oversight? I&#39;m not familiar with compi=
ler design but it would seem to me to be a trivial thing to prove that ever=
y way of returning from this function actually returned an int.</div><div><=
br></div><div><font face=3D"courier new, monospace">int Foo(int valueIn)</f=
ont></div><div><font face=3D"courier new, monospace">{</font></div><div><fo=
nt face=3D"courier new, monospace">=C2=A0 =C2=A0 if (valueIn =3D=3D 5) retu=
rn 15;</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
 // Compilation error because for all other values of valueIn</font></div><=
div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 // there is no int =
returned.</font></div><div><span style=3D"font-family: &#39;courier new&#39=
;, monospace;">}</span><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3758_610848860.1444770081835--
------=_Part_3757_576094496.1444770081835--

.

This is a top post - new contents added at the top, making readers have
to start from the bottom to follow the thread.

Some people don't like to do that.

On 2015-10-13 22:56, keith.f.kelly@gmail.com wrote:
> Sorry, but I don't know what you mean by "top post".
>
> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>
>     Please don't top-post; it makes it harder to follow the conversation.
>


--

---
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 2015-10-13 23:01, keith.f.kelly@gmail.com wrote:
> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>
>     No, it can't. *Some* compilers can attempt to solve this problem with a
>     low rate of false positives, and even that is *hard*. Proposing to
>     require that *every* conforming compiler must do so *perfectly* is not
>     likely to go over well.
>
> Every C++ compiler I've ever encountered will produce an error if you
> write a function like this, because not every execution path returns a
> value, and the function signatures requires that the function return a
> value. Are you saying not all compilers will error on this kind of
> programmer oversight? I'm not familiar with compiler design but it would
> seem to me to be a trivial thing to prove that every way of returning
> from this function actually returned an int.
>
> int Foo(int valueIn)
> {
>      if (valueIn == 5) return 15;
>      // Compilation error because for all other values of valueIn
>      // there is no int returned.
> }
>

But what if Foo(5) is the only way the function is ever called?

Or if the parameter is not an int, and the overloaded operator== throws
an exception rather than return false?

This quickly becomes nasty?


Bo Persson



--

---
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/.

.

------=_Part_7854_1189161105.1444770703191
Content-Type: multipart/alternative;
 boundary="----=_Part_7855_729625530.1444770703192"

------=_Part_7855_729625530.1444770703192
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:05:25 PM UTC-7, Bo Persson wrote:
>
> This is a top post - new contents added at the top, making readers have
> to start from the bottom to follow the thread.
>

Got it, thanks.  I didn't do that intentionally, it's just the default when
you hit "reply" in these forums -- the text editor is automatically
pre-populated with the entire thread thus far to which you are replying,
and your cursor is placed above it all.  If that's annoying to people, then
perhaps the default forum behavior should be fixed.

--

---
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/.

------=_Part_7855_729625530.1444770703192
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:05:25 PM UTC-7, Bo Perss=
on wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This is a top post - =
new contents added at the top, making readers have=20
<br>to start from the bottom to follow the thread.
<br></blockquote><div><br></div><div>Got it, thanks. =C2=A0I didn&#39;t do =
that intentionally, it&#39;s just the default when you hit &quot;reply&quot=
; in these forums -- the text editor is automatically pre-populated with th=
e entire thread thus far to which you are replying, and your cursor is plac=
ed above it all. =C2=A0If that&#39;s annoying to people, then perhaps the d=
efault forum behavior should be fixed.=C2=A0</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7855_729625530.1444770703192--
------=_Part_7854_1189161105.1444770703191--

.

On Tue, Oct 13, 2015 at 6:09 PM, Bo Persson <bop@gmb.dk> wrote:
> On 2015-10-13 23:01, keith.f.kelly@gmail.com wrote:
>>
>> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>>
>>     No, it can't. *Some* compilers can attempt to solve this problem wit=
h
>> a
>>     low rate of false positives, and even that is *hard*. Proposing to
>>     require that *every* conforming compiler must do so *perfectly* is n=
ot
>>     likely to go over well.
>>
>> Every C++ compiler I've ever encountered will produce an error if you
>> write a function like this, because not every execution path returns a
>> value, and the function signatures requires that the function return a
>> value. Are you saying not all compilers will error on this kind of
>> programmer oversight? I'm not familiar with compiler design but it would
>> seem to me to be a trivial thing to prove that every way of returning
>> from this function actually returned an int.
>>
>> int Foo(int valueIn)
>> {
>>      if (valueIn =3D=3D 5) return 15;
>>      // Compilation error because for all other values of valueIn
>>      // there is no int returned.
>> }
>>
>
> But what if Foo(5) is the only way the function is ever called?
>
> Or if the parameter is not an int, and the overloaded operator=3D=3D thro=
ws an
> exception rather than return false?

Or if the function does "return anotherFunction();" and
anotherFunction is not visible in the compilation unit?
Maybe such function "does the right thing" but the compiler has no
means to determine that.

>
> This quickly becomes nasty?
>
>
> Bo Persson
>
>
>
>
> --
>
> --- 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/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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_952_574504153.1444770974066
Content-Type: multipart/alternative;
 boundary="----=_Part_953_1355501805.1444770974066"

------=_Part_953_1355501805.1444770974066
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 5:01:21 PM UTC-4, keith....@gmail.com wrote:
>
> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>>
>> No, it can't. *Some* compilers can attempt to solve this problem with a
>> low rate of false positives, and even that is *hard*. Proposing to
>> require that *every* conforming compiler must do so *perfectly* is not
>> likely to go over well.
>>
>
> Every C++ compiler I've ever encountered will produce an error if you
> write a function like this, because not every execution path returns a
> value, and the function signatures requires that the function return a
> value.
>

Not this one. <http://ideone.com/frIFM6>

Oh, it produces a *warning*. But unless you're compiling warnings as
errors, those are two different things.


> Are you saying not all compilers will error on this kind of programmer
> oversight? I'm not familiar with compiler design but it would seem to me to
> be a trivial thing to prove that every way of returning from this function
> actually returned an int.
>

Really?

int Foo()
{
  if(SomeFunctionNotInCompilationUnit())
    return 5;

  if(SomeFunctionNotInCompilationUnit2())
    return 10;
}

Is this function legal or illegal? Well, it rather depends on what those
two functions return. But since the compiler cannot possibly see the
definition of those functions... it has no idea.

The definition of those function could be such that at least one of them
will always return true. If so, there is no reason why this code should
*fail* to compile. But since the compiler cannot know for certain, the
compiler is not required to fail.

Indeed, the compiler is not *allowed to fail* in this case. The C++
standard says that this code is perfectly well-formed... so long as
execution doesn't escape the bottom. If your compiler refuses to compile
this code, then it is broken.

The compiler can issue a warning. But it must allow this to compile.

--

---
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/.

------=_Part_953_1355501805.1444770974066
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 5:01:21 PM UTC-4, keith...=
..@gmail.com wrote:<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">On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">No, it can&#39;t. *Some* compiler=
s can attempt to solve this problem with a
<br>low rate of false positives, and even that is *hard*. Proposing to
<br>require that *every* conforming compiler must do so *perfectly* is not
<br>likely to go over well.
<br></blockquote><div>=C2=A0</div><div>Every C++ compiler I&#39;ve ever enc=
ountered will produce an error if you write a function like this, because n=
ot every execution path returns a value, and the function signatures requir=
es that the function return a value.</div></div></blockquote><div><br><a hr=
ef=3D"http://ideone.com/frIFM6">Not this one.</a><br><br>Oh, it produces a =
<i>warning</i>. But unless you&#39;re compiling warnings as errors, those a=
re two different things.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div> Are you saying not all compilers will erro=
r on this kind of programmer oversight? I&#39;m not familiar with compiler =
design but it would seem to me to be a trivial thing to prove that every wa=
y of returning from this function actually returned an int.</div></div></bl=
ockquote><div><br>Really?<br><br>int Foo()<br>{<br>=C2=A0 if(SomeFunctionNo=
tInCompilationUnit())<br>=C2=A0=C2=A0=C2=A0 return 5;<br><br>=C2=A0 if(Some=
FunctionNotInCompilationUnit2())<br>=C2=A0=C2=A0=C2=A0 return 10;<br>}<br>=
=C2=A0<br>Is this function legal or illegal? Well, it rather depends on wha=
t those two functions return. But since the compiler cannot possibly see th=
e definition of those functions... it has no idea.<br><br>The definition of=
 those function could be such that at least one of them will always return =
true. If so, there is no reason why this code should <i>fail</i> to compile=
.. But since the compiler cannot know for certain, the compiler is not requi=
red to fail.<br><br>Indeed, the compiler is not <i>allowed to fail</i> in t=
his case. The C++ standard says that this code is perfectly well-formed... =
so long as execution doesn&#39;t escape the bottom. If your compiler refuse=
s to compile this code, then it is broken.<br><br>The compiler can issue a =
warning. But it must allow this to compile.<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_953_1355501805.1444770974066--
------=_Part_952_574504153.1444770974066--

.

------=_Part_605_459184157.1444771113573
Content-Type: multipart/alternative;
 boundary="----=_Part_606_319547943.1444771113573"

------=_Part_606_319547943.1444771113573
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:10:11 PM UTC-7, Bo Persson wrote:
>
> But what if Foo(5) is the only way the function is ever called?
>

That doesn't matter.  The fact that there's a possible return path that
doesn't return an int should always be an error.  It doesn't matter how the
function actually gets called.

On Tuesday, October 13, 2015 at 2:10:11 PM UTC-7, Bo Persson wrote:

> Or if the parameter is not an int, and the overloaded operator== throws
> an exception rather than return false?


Exceptions also shouldn't matter in terms of this kind of validation by the
compiler.  Yes, exceptions can always get thrown, at which point all bets
are off and execution flow has effectively been hijacked via catch
handlers.  The compiler should validate this method's return paths assuming
no exceptions get thrown along the way.

Maybe you just chose weak examples and there's something else I'm missing
here?

--

---
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/.

------=_Part_606_319547943.1444771113573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:10:11 PM UTC-7, Bo Perss=
on wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But what if Foo(5) is=
 the only way the function is ever called?
<br></blockquote><div><br></div><div>That doesn&#39;t matter. =C2=A0The fac=
t that there&#39;s a possible return path that doesn&#39;t return an int sh=
ould always be an error. =C2=A0It doesn&#39;t matter how the function actua=
lly gets called.</div><div><br></div><div>On Tuesday, October 13, 2015 at 2=
:10:11 PM UTC-7, Bo Persson wrote:=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">Or if the parameter is not an int, and the overloaded opera=
tor=3D=3D throws=20
<br>an exception rather than return false?</blockquote><div><br></div><div>=
Exceptions also shouldn&#39;t matter in terms of this kind of validation by=
 the compiler. =C2=A0Yes, exceptions can always get thrown, at which point =
all bets are off and execution flow has effectively been hijacked via catch=
 handlers. =C2=A0The compiler should validate this method&#39;s return path=
s assuming no exceptions get thrown along the way.</div><div><br></div><div=
>Maybe you just chose weak examples and there&#39;s something else I&#39;m =
missing here?</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_606_319547943.1444771113573--
------=_Part_605_459184157.1444771113573--

.

On 2015-10-13 16:56, keith.f.kelly@gmail.com wrote:
> Sorry, but I don't know what you mean by "top post".

https://en.wikipedia.org/wiki/Posting_style#Top-posting

(BTW, gmail's interface is junk; that's why I use thunderbird and
news://news.gmane.org/gmane.comp.lang.c++.isocpp.proposals ;-).)

On 2015-10-13 17:01, keith.f.kelly@gmail.com wrote:
> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>> No, it can't. *Some* compilers can attempt to solve this problem with a=
=20
>> low rate of false positives, and even that is *hard*. Proposing to=20
>> require that *every* conforming compiler must do so *perfectly* is not=
=20
>> likely to go over well.=20
> =20
> Every C++ compiler I've ever encountered will produce an error if you wri=
te=20
> a function like this,

Really? I've yet to encounter a single one. (I'm taking your wording
"will" literally, as in "by default". Which, much as I wish otherwise,
is not the case.)

> because not every execution path returns a value, and=20
> the function signatures requires that the function return a value. Are yo=
u=20
> saying not all compilers will error on this kind of programmer oversight?

Have you used any compiler other than GCC, Clang, MSVC and *possibly*
ICC? Because AFAIK this is a hard - if not impossible=C2=B9 - problem to
solve perfectly. Trying to enforce that on everyone that wants to write
their own compiler seems likely to meet with resistance.

(=C2=B9 https://en.wikipedia.org/wiki/Halting_problem)

> I'm not familiar with compiler design but it would seem to me to be a=20
> trivial thing to prove that every way of returning from this function=20
> actually returned an int.

Let's pretend this is an override of an "extendable" method:

  enum Foo { A, B };
  int Derived::foo(Foo f)
  {
    switch (f)
    {
      case A:
        return 1 + Base::foo(f);
      case B:
        return 2 + Base::foo(f);
    }
  }

I expect you'd have a hard time convincing the committee to make that
ill-formed... either due to your proposal, or simply because it "doesn't
always return a value".

--=20
Matthew

--=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/.

.

--001a11c38b984f2efb052203302c
Content-Type: text/plain; charset=UTF-8

On 13 October 2015 at 21:06, <keith.f.kelly@gmail.com> wrote:

> 1) Yes, but not just anywhere. It must appear exactly once along each
> execution path that leads to a return from the function.
>
> 2) No, because base::foo() won't actually get executed.
>
> On Tuesday, October 13, 2015 at 11:24:35 AM UTC-7, Brent Friedman wrote:
>>
>> Are you saying that the token sequence "base::foo( ... );" must appear in
>> the body of the function?
>>
>> Does if(false) base::foo(); properly extend an extendable function?
>>
>> I agree that dependency inversion usually solves these issues, but I can
>> imagine cases where that's not a good way to solve the problem.
>>
>> On Tue, Oct 13, 2015 at 12:59 PM, Christopher Horvath <black...@gmail.com
>> > wrote:
>>
>>> On one hand, I think that this is one of those design situations where
>>> you can always fix the problem with a layer of indirection:
>>>
>>> class BaseClass {
>>> public:
>>>      void doTheThing(etc) { internalDoTheThing(etc);
>>> doBaseClassStuff(etc); }
>>> protected:
>>>      virtual void internalDoTheThing(etc) { /* nothing */ }  // Or = 0;
>>> };
>>>
>>> On the other hand... this bugs from this exact problem bite us once a
>>> month, at least. We literally had two bugs filed yesterday which were both
>>> related to a user deriving from a base class and forgetting to call the
>>> base version of a virtual function, despite clear documentation indicating
>>> that this was necessary.
>>>
>>> So - I don't think it is strictly necessary, but if it existed, we'd use
>>> it religiously.
>>>
>>> Chris
>>>
>>
sorry if i've missed you mentioning this is another post, but just out of
interest -- what's wrong with this method?

you could even extend it if you wanted to give the user more control:

class foo {
public:
  void key_press() { before_key_press(); do_base_class_stuff();
after_key_press(); }

private:
  virtual void before_key_press() {}
  virtual void after_key_press() {}
};

basically something like this:
http://api.rubyonrails.org/classes/ActiveRecord/Callbacks.html

--

---
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/.

--001a11c38b984f2efb052203302c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 13 October 2015 at 21:06,  <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:keith.f.kelly@gmail.com" target=3D"_blank">keith.f.kelly@gmail.=
com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
1) Yes, but not just anywhere. It must appear exactly once along each execu=
tion path that leads to a return from the function.<div><br><div>2) No, bec=
ause base::foo() won&#39;t actually get executed.</div><div><span><br>On Tu=
esday, October 13, 2015 at 11:24:35 AM UTC-7, Brent Friedman wrote:</span><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><span><div dir=3D"ltr"><di=
v>Are you saying that the token sequence &quot;base::foo( ... );&quot; must=
 appear in the body of the function?<br></div><div><br></div><div>Does if(f=
alse) base::foo(); properly extend an extendable function?</div><div><br></=
div><div>I agree that dependency inversion usually solves these issues, but=
 I can imagine cases where that&#39;s not a good way to solve the problem.<=
/div></div></span><div><br><div class=3D"gmail_quote"><span>On Tue, Oct 13,=
 2015 at 12:59 PM, Christopher Horvath <span dir=3D"ltr">&lt;<a rel=3D"nofo=
llow">black...@gmail.com</a>&gt;</span> wrote:<br></span><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><span><div dir=3D"ltr">On one hand, I thin=
k that this is one of those design situations where you can always fix the =
problem with a layer of indirection:<div><br></div><div><font face=3D"monos=
pace, monospace">class BaseClass {</font></div><div><font face=3D"monospace=
, monospace">public:</font></div><div><font face=3D"monospace, monospace">=
=C2=A0 =C2=A0 =C2=A0void doTheThing(etc) { internalDoTheThing(etc); doBaseC=
lassStuff(etc); }</font></div><div><font face=3D"monospace, monospace">prot=
ected:</font></div><div><font face=3D"monospace, monospace">=C2=A0 =C2=A0 =
=C2=A0virtual void internalDoTheThing(etc) { /* nothing */ } =C2=A0// Or =
=3D 0;</font></div><div><font face=3D"monospace, monospace">};</font></div>=
<div><br></div><div>On the other hand... this bugs from this exact problem =
bite us once a month, at least. We literally had two bugs filed yesterday w=
hich were both related to a user deriving from a base class and forgetting =
to call the base version of a virtual function, despite clear documentation=
 indicating that this was necessary.</div><div><br></div><div>So - I don&#3=
9;t think it is strictly necessary, but if it existed, we&#39;d use it reli=
giously.</div><div><br></div><div>Chris</div></div></span></blockquote></di=
v></div></blockquote></div></div></div></blockquote></div><br></div><div cl=
ass=3D"gmail_extra">sorry if i&#39;ve missed you mentioning this is another=
 post, but just out of interest -- what&#39;s wrong with this method?<br><b=
r></div><div class=3D"gmail_extra">you could even extend it if you wanted t=
o give the user more control:<br><br></div><div class=3D"gmail_extra">class=
 foo {<br></div><div class=3D"gmail_extra">public:<br></div><div class=3D"g=
mail_extra">=C2=A0 void key_press() { before_key_press(); do_base_class_stu=
ff(); after_key_press(); }<br><br></div><div class=3D"gmail_extra">private:=
<br></div><div class=3D"gmail_extra">=C2=A0 virtual void before_key_press()=
 {}<br></div><div class=3D"gmail_extra">=C2=A0 virtual void after_key_press=
() {}<br></div><div class=3D"gmail_extra">};<br><br></div><div class=3D"gma=
il_extra">basically something like this: <a href=3D"http://api.rubyonrails.=
org/classes/ActiveRecord/Callbacks.html">http://api.rubyonrails.org/classes=
/ActiveRecord/Callbacks.html</a></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11c38b984f2efb052203302c--

.

--001a1142e648b68e7e052203321f
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 10:35 AM, <keith.f.kelly@gmail.com> wrote:

> *Motivation*
> Many frameworks (Qt being one great example) require a client-defined
> framework-derived class to call the framework-provided base method when
> overriding a given base class virtual method.  I've encountered many bugs
> that were caused by a developer forgetting/neglecting to call the (correct)
> base method from their overriding implementation.
>

As has been mentioned, this is something that cannot be realistically
enforced, even if you restrict it to only looking at the body of overriding
functions (which, imo, would be a rather impractical restriction). I'm also
not entirely convinced that simply checking that the user calls the parent
function fully solves the problems that you are aiming to solve. For
instance, the order of the invocation in these situations is often
important in addition to the fact that it is logically called (i.e. the
parent should be called first). As well, would you require that the parent
function is invoked with exactly the same objects? What about copies of the
objects? Further, even in the case that you want children to *logically*
invoke the parent function, often the *actual* intent is just that the
overall behavior of the child call should be functionally equivalent to
invoking the parent function along with some additional operation. This may
or may not involve actually calling the parent implementation.

In short, I don't think that the pattern you are trying to look for is
entirely consistent with the overall expectations of such functions, and in
many cases (depending on the situation) the Template Method pattern already
works here. I could *maybe* see some kind of function that automatically
calls the parent function for you rather than a facility that tries to
identify patterns, but for the reasons mentioned above, I think that even
this is unnecessarily restrictive, even though it is more likely to be
implementable.

--

---
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/.

--001a1142e648b68e7e052203321f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 10:35 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:keit=
h.f.kelly@gmail.com" target=3D"_blank">keith.f.kelly@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b><font size=
=3D"4">Motivation</font></b><div><font size=3D"2">Many frameworks (Qt being=
 one great example) require a client-defined framework-derived class to cal=
l the framework-provided base method when overriding a given base class vir=
tual method.=C2=A0 I&#39;ve encountered many bugs that were caused by a dev=
eloper forgetting/neglecting to call the (correct) base method from their o=
verriding implementation.</font></div></div></blockquote><div><br></div><di=
v>As has been mentioned, this is something that cannot be realistically enf=
orced, even if you restrict it to only looking at the body of overriding fu=
nctions (which, imo, would be a rather impractical restriction). I&#39;m al=
so not entirely convinced that simply checking that the user calls the pare=
nt function fully solves the problems that you are aiming to solve. For ins=
tance, the order of the invocation in these situations is often important i=
n addition to the fact that it is logically called (i.e. the parent should =
be called first). As well, would you require that the parent function is in=
voked with exactly the same objects? What about copies of the objects? Furt=
her, even in the case that you want children to <i>logically</i> invoke the=
 parent function, often the <i>actual</i> intent is just that the overall b=
ehavior of the child call should be functionally equivalent to invoking the=
 parent function along with some additional operation. This may or may not =
involve actually calling the parent implementation.</div><div><br></div><di=
v>In short, I don&#39;t think that the pattern you are trying to look for i=
s entirely consistent with the overall expectations of such functions, and =
in many cases (depending on the situation) the Template Method pattern alre=
ady works here. I could <i>maybe</i>=C2=A0see some kind of function that au=
tomatically calls the parent function for you rather than a facility that t=
ries to identify patterns, but for the reasons mentioned above, I think tha=
t even this is unnecessarily restrictive, even though it is more likely to =
be implementable.</div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a1142e648b68e7e052203321f--

.

On Tue, Oct 13, 2015 at 6:24 PM, Matthew Woehlke
<mwoehlke.floss@gmail.com> wrote:
> On 2015-10-13 16:56, keith.f.kelly@gmail.com wrote:
>> Sorry, but I don't know what you mean by "top post".
>
> https://en.wikipedia.org/wiki/Posting_style#Top-posting
>
> (BTW, gmail's interface is junk; that's why I use thunderbird and
> news://news.gmane.org/gmane.comp.lang.c++.isocpp.proposals ;-).)
>
> On 2015-10-13 17:01, keith.f.kelly@gmail.com wrote:
>> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>>> No, it can't. *Some* compilers can attempt to solve this problem with a
>>> low rate of false positives, and even that is *hard*. Proposing to
>>> require that *every* conforming compiler must do so *perfectly* is not
>>> likely to go over well.
>>
>> Every C++ compiler I've ever encountered will produce an error if you wr=
ite
>> a function like this,
>
> Really? I've yet to encounter a single one. (I'm taking your wording
> "will" literally, as in "by default". Which, much as I wish otherwise,
> is not the case.)
>
>> because not every execution path returns a value, and
>> the function signatures requires that the function return a value. Are y=
ou
>> saying not all compilers will error on this kind of programmer oversight=
?
>
> Have you used any compiler other than GCC, Clang, MSVC and *possibly*
> ICC? Because AFAIK this is a hard - if not impossible=C2=B9 - problem to
> solve perfectly. Trying to enforce that on everyone that wants to write
> their own compiler seems likely to meet with resistance.
>
> (=C2=B9 https://en.wikipedia.org/wiki/Halting_problem)
>
>> I'm not familiar with compiler design but it would seem to me to be a
>> trivial thing to prove that every way of returning from this function
>> actually returned an int.
>
> Let's pretend this is an override of an "extendable" method:
>
>   enum Foo { A, B };
>   int Derived::foo(Foo f)
>   {
>     switch (f)
>     {
>       case A:
>         return 1 + Base::foo(f);
>       case B:
>         return 2 + Base::foo(f);
>     }
>   }

even something like:

const auto x =3D Base::foo(f);
return x + 1;
is it OK?

>
> I expect you'd have a hard time convincing the committee to make that
> ill-formed... either due to your proposal, or simply because it "doesn't
> always return a value".
>
> --
> Matthew
>
> --
>
> ---
> 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-propo=
sals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=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_3116_349199520.1444772215699
Content-Type: multipart/alternative;
 boundary="----=_Part_3117_101151787.1444772215700"

------=_Part_3117_101151787.1444772215700
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 13, 2015 at 2:25:03 PM UTC-7, Matthew Woehlke wrote:
>
> Let's pretend this is an override of an "extendable" method:
>
>   enum Foo { A, B };
>   int Derived::foo(Foo f)
>   {
>     switch (f)
>     {
>       case A:
>         return 1 + Base::foo(f);
>       case B:
>         return 2 + Base::foo(f);
>     }
>   }
>
> I expect you'd have a hard time convincing the committee to make that
> ill-formed... either due to your proposal, or simply because it "doesn't
> always return a value".
>

That wouldn't be ill-formed because all possible return paths call the base
method and return an int.

--

---
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/.

------=_Part_3117_101151787.1444772215700
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 13, 2015 at 2:25:03 PM UTC-7, =
Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Let&#39;=
s pretend this is an override of an &quot;extendable&quot; method:
<br>
<br>=C2=A0 enum Foo { A, B };
<br>=C2=A0 int Derived::foo(Foo f)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 switch (f)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 case A:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 1 + Base::foo(f);
<br>=C2=A0 =C2=A0 =C2=A0 case B:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 2 + Base::foo(f);
<br>=C2=A0 =C2=A0 }
<br>=C2=A0 }
<br>
<br>I expect you&#39;d have a hard time convincing the committee to make th=
at
<br>ill-formed... either due to your proposal, or simply because it &quot;d=
oesn&#39;t
<br>always return a value&quot;.<br></blockquote><div><br></div><div>That w=
ouldn&#39;t be ill-formed because all possible return paths call the base m=
ethod and return an int.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3117_101151787.1444772215700--
------=_Part_3116_349199520.1444772215699--

.

--001a1142e64899dd300522034252
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 2:36 PM, <keith.f.kelly@gmail.com> wrote:

>
>
> On Tuesday, October 13, 2015 at 2:25:03 PM UTC-7, Matthew Woehlke wrote:
>>
>> Let's pretend this is an override of an "extendable" method:
>>
>>   enum Foo { A, B };
>>   int Derived::foo(Foo f)
>>   {
>>     switch (f)
>>     {
>>       case A:
>>         return 1 + Base::foo(f);
>>       case B:
>>         return 2 + Base::foo(f);
>>     }
>>   }
>>
>> I expect you'd have a hard time convincing the committee to make that
>> ill-formed... either due to your proposal, or simply because it "doesn't
>> always return a value".
>>
>
> That wouldn't be ill-formed because all possible return paths call the
> base method and return an int.
>

No they don't. Foo doesn't have to be A or B.

--

---
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/.

--001a1142e64899dd300522034252
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 2:36 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:keith=
..f.kelly@gmail.com" target=3D"_blank">keith.f.kelly@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"=
"><br><br>On Tuesday, October 13, 2015 at 2:25:03 PM UTC-7, Matthew Woehlke=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">Let&#39;s pretend this is an=
 override of an &quot;extendable&quot; method:
<br>
<br>=C2=A0 enum Foo { A, B };
<br>=C2=A0 int Derived::foo(Foo f)
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 switch (f)
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 case A:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 1 + Base::foo(f);
<br>=C2=A0 =C2=A0 =C2=A0 case B:
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 return 2 + Base::foo(f);
<br>=C2=A0 =C2=A0 }
<br>=C2=A0 }
<br>
<br>I expect you&#39;d have a hard time convincing the committee to make th=
at
<br>ill-formed... either due to your proposal, or simply because it &quot;d=
oesn&#39;t
<br>always return a value&quot;.<br></blockquote><div><br></div></span><div=
>That wouldn&#39;t be ill-formed because all possible return paths call the=
 base method and return an int.</div></div></blockquote><div><br></div><div=
>No they don&#39;t. Foo doesn&#39;t have to be A or B.=C2=A0</div></div><br=
></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a1142e64899dd300522034252--

.

------=_Part_7580_557653457.1444772324272
Content-Type: multipart/alternative;
 boundary="----=_Part_7581_1457664987.1444772324272"

------=_Part_7581_1457664987.1444772324272
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, October 13, 2015 at 2:25:03 PM UTC-7, Matthew Woehlke wrote:
>
> Have you used any compiler other than GCC, Clang, MSVC and *possibly*=20
> ICC?


Nope, can't say that I have.
=20

> Because AFAIK this is a hard - if not impossible=C2=B9 - problem to=20
> solve perfectly. Trying to enforce that on everyone that wants to write=
=20
> their own compiler seems likely to meet with resistance.


Fair enough.  I was just under the impression it wasn't a difficult=20
problem.  Like I said earlier, I'm not an expert on how compilers are=20
design or how they work, I'm just a user of the C++ language.=20

--=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_7581_1457664987.1444772324272
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:25:03 PM UTC-7, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Have you used an=
y compiler other than GCC, Clang, MSVC and *possibly*
<br>ICC?</blockquote><div><br></div><div>Nope, can&#39;t say that I have.</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> Because =
AFAIK this is a hard - if not impossible=C2=B9 - problem to
<br>solve perfectly. Trying to enforce that on everyone that wants to write
<br>their own compiler seems likely to meet with resistance.</blockquote><d=
iv><br></div><div>Fair enough. =C2=A0I was just under the impression it was=
n&#39;t a difficult problem. =C2=A0Like I said earlier, I&#39;m not an expe=
rt on how compilers are design or how they work, I&#39;m just a user of the=
 C++ language.=C2=A0</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7581_1457664987.1444772324272--
------=_Part_7580_557653457.1444772324272--

.

Am 13.10.2015 um 23:24 schrieb Matthew Woehlke:
> On 2015-10-13 16:56, keith.f.kelly@gmail.com wrote:
>> Sorry, but I don't know what you mean by "top post".
> https://en.wikipedia.org/wiki/Posting_style#Top-posting
>
> (BTW, gmail's interface is junk; that's why I use thunderbird and
> news://news.gmane.org/gmane.comp.lang.c++.isocpp.proposals ;-).)
>
> On 2015-10-13 17:01, keith.f.kelly@gmail.com wrote:
>> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>>> No, it can't. *Some* compilers can attempt to solve this problem with a
>>> low rate of false positives, and even that is *hard*. Proposing to
>>> require that *every* conforming compiler must do so *perfectly* is not
>>> likely to go over well.
>>  =20
>> Every C++ compiler I've ever encountered will produce an error if you wr=
ite
>> a function like this,
> Really? I've yet to encounter a single one. (I'm taking your wording
> "will" literally, as in "by default". Which, much as I wish otherwise,
> is not the case.)
>
>> because not every execution path returns a value, and
>> the function signatures requires that the function return a value. Are y=
ou
>> saying not all compilers will error on this kind of programmer oversight=
?
> Have you used any compiler other than GCC, Clang, MSVC and *possibly*
> ICC? Because AFAIK this is a hard - if not impossible=C2=B9 - problem to
> solve perfectly. Trying to enforce that on everyone that wants to write
> their own compiler seems likely to meet with resistance.
>
> (=C2=B9 https://en.wikipedia.org/wiki/Halting_problem)
This is unrelated to the halting problem. Every compiler worth its salt=20
has to produce some form of control flow graph which makes it trivial to=20
detect whether all paths to leaf nodes have a certain property with a=20
plain DSF from the function entry point. This is not rocket science. The=20
OP has stated that he is interested only in direct calls to the base=20
implementation, not accounting for transitive calls.
>
>> I'm not familiar with compiler design but it would seem to me to be a
>> trivial thing to prove that every way of returning from this function
>> actually returned an int.
> Let's pretend this is an override of an "extendable" method:
>
>    enum Foo { A, B };
>    int Derived::foo(Foo f)
>    {
>      switch (f)
>      {
>        case A:
>          return 1 + Base::foo(f);
>        case B:
>          return 2 + Base::foo(f);
>      }
>    }
>
> I expect you'd have a hard time convincing the committee to make that
> ill-formed... either due to your proposal, or simply because it "doesn't
> always return a value".
>
"extendable" or not, this function has UB because an enum can have *any*=20
value of the underlying type. The compiler has to assume the switch does=20
not hit any case. There is an edge in the CFG from the entry point to=20
the end of the function that does not contain a return.

--=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_7754_1176240969.1444772536775
Content-Type: multipart/alternative;
 boundary="----=_Part_7755_1027707892.1444772536775"

------=_Part_7755_1027707892.1444772536775
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:14:40 PM UTC-7, dgutson wrote:
>
> > But what if Foo(5) is the only way the function is ever called?
>

Doesn't matter -- the function would still by syntactically ill-formed
because its signature allows it to be called with other values.

Or if the function does "return anotherFunction();" and
> anotherFunction is not visible in the compilation unit?


Doesn't matter -- the compiler already requires that the signature
(declaration) of anotherFunction be known at that point, which means its
return type is known.  All that matters is that its a way of returning from
the function, and that way can be validated as returning the correct type.

Referring back to my proposal, if anotherFunction() called base::Foo(),
that wouldn't count as valid.  The point of the new specifier would be to
require a direct literal call to base::Foo() before every possible
non-exceptional return path from the 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/.

------=_Part_7755_1027707892.1444772536775
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:14:40 PM UTC-7, dgutson =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; But what if Foo(5) =
is the only way the function is ever called?
<br></blockquote><div><br></div><div>Doesn&#39;t matter -- the function wou=
ld still by syntactically ill-formed because its signature allows it to be =
called with other values.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">Or if the function does &quot;return anotherFunction();&quo=
t; and
<br>anotherFunction is not visible in the compilation unit?</blockquote><di=
v><br></div><div>Doesn&#39;t matter -- the compiler already requires that t=
he signature (declaration) of anotherFunction be known at that point, which=
 means its return type is known. =C2=A0All that matters is that its a way o=
f returning from the function, and that way can be validated as returning t=
he correct type.</div><div><br></div><div>Referring back to my proposal, if=
 anotherFunction() called base::Foo(), that wouldn&#39;t count as valid. =
=C2=A0The point of the new specifier would be to require a direct literal c=
all to base::Foo() before every possible non-exceptional return path from t=
he function.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7755_1027707892.1444772536775--
------=_Part_7754_1176240969.1444772536775--

.

------=_Part_4465_389879770.1444772706573
Content-Type: multipart/alternative;
 boundary="----=_Part_4466_1632727503.1444772706573"

------=_Part_4466_1632727503.1444772706573
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:
>
> int Foo()
> {
>   if(SomeFunctionNotInCompilationUnit())
>     return 5;
>
>   if(SomeFunctionNotInCompilationUnit2())
>     return 10;
> }
>
> Is this function legal or illegal? Well, it rather depends on what those
> two functions return. But since the compiler cannot possibly see the
> definition of those functions... it has no idea.
>

That sounds wrong.  The declaration/signature must be known by the compiler
at that point, right?  Otherwise you'd get an "unknown symbol" error.  If
the declaration/signatures is known, then the return type is known. If the
return type is known, that's all you need to validate this function.

It doesn't matter what each of those functions actually does. All that
matters is that their declarations/signatures mean it's possible they could
return 'false', which means this function doesn't return an int for every
possible codepath. So it should be at least a warning if not an error.

--

---
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/.

------=_Part_4466_1632727503.1444772706573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>int Foo()<br>{<br>=C2=A0 if(<wbr>SomeFunctionNotInCompilationUn<wbr>it())=
<br>=C2=A0=C2=A0=C2=A0 return 5;<br><br>=C2=A0 if(<wbr>SomeFunctionNotInCom=
pilationUn<wbr>it2())<br>=C2=A0=C2=A0=C2=A0 return 10;<br>}<br>=C2=A0<br>Is=
 this function legal or illegal? Well, it rather depends on what those two =
functions return. But since the compiler cannot possibly see the definition=
 of those functions... it has no idea.<br></div></div></blockquote><div><br=
></div><div>That sounds wrong. =C2=A0The declaration/signature must be know=
n by the compiler at that point, right? =C2=A0Otherwise you&#39;d get an &q=
uot;unknown symbol&quot; error. =C2=A0If the declaration/signatures is know=
n, then the return type is known. If the return type is known, that&#39;s a=
ll you need to validate this function.</div><div><br></div><div>It doesn&#3=
9;t matter what each of those functions actually does. All that matters is =
that their declarations/signatures mean it&#39;s possible they could return=
 &#39;false&#39;, which means this function doesn&#39;t return an int for e=
very possible codepath. So it should be at least a warning if not an error.=
=C2=A0</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_4466_1632727503.1444772706573--
------=_Part_4465_389879770.1444772706573--

.

--089e0115f05244fa500522036739
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 2:42 PM, <keith.f.kelly@gmail.com> wrote:

> On Tuesday, October 13, 2015 at 2:14:40 PM UTC-7, dgutson wrote:
>>
>> > But what if Foo(5) is the only way the function is ever called?
>>
>
> Doesn't matter -- the function would still by syntactically ill-formed
> because its signature allows it to be called with other values.
>
> Or if the function does "return anotherFunction();" and
>> anotherFunction is not visible in the compilation unit?
>
>
> Doesn't matter -- the compiler already requires that the signature
> (declaration) of anotherFunction be known at that point, which means its
> return type is known.  All that matters is that its a way of returning from
> the function, and that way can be validated as returning the correct type.
>
> Referring back to my proposal, if anotherFunction() called base::Foo(),
> that wouldn't count as valid.  The point of the new specifier would be to
> require a direct literal call to base::Foo() before every possible
> non-exceptional return path from the function.
>

You can propose such restrictions for your extendable function, but
understand that it is somewhat inconsistent with the way return statements
are treated in the current standard, so you'd probably need to have a
convincing rationale for why it makes sense here.

On Tue, Oct 13, 2015 at 2:42 PM, <keith.f.kelly@gmail.com> wrote:
>
> Referring back to my proposal, if anotherFunction() called base::Foo(),
> that wouldn't count as valid.  The point of the new specifier would be to
> require a direct literal call to base::Foo() before every possible
> non-exceptional return path from the function.
>

This seems to be overly restrictive, at least imo.

--

---
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/.

--089e0115f05244fa500522036739
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 2:42 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:keith=
..f.kelly@gmail.com" target=3D"_blank">keith.f.kelly@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Tuesday, =
October 13, 2015 at 2:14:40 PM UTC-7, dgutson wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">&gt; B=
ut what if Foo(5) is the only way the function is ever called?
<br></blockquote><div><br></div></span><div>Doesn&#39;t matter -- the funct=
ion would still by syntactically ill-formed because its signature allows it=
 to be called with other values.</div><span class=3D""><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">Or if the function does &quot;return anotherFunction();&quot; a=
nd
<br>anotherFunction is not visible in the compilation unit?</blockquote><di=
v><br></div></span><div>Doesn&#39;t matter -- the compiler already requires=
 that the signature (declaration) of anotherFunction be known at that point=
, which means its return type is known.=C2=A0 All that matters is that its =
a way of returning from the function, and that way can be validated as retu=
rning the correct type.</div><div><br></div><div>Referring back to my propo=
sal, if anotherFunction() called base::Foo(), that wouldn&#39;t count as va=
lid.=C2=A0 The point of the new specifier would be to require a direct lite=
ral call to base::Foo() before every possible non-exceptional return path f=
rom the function.</div></div></blockquote><div><br></div><div>You can propo=
se such restrictions for your extendable function, but understand that it i=
s somewhat inconsistent with the way return statements are treated in the c=
urrent standard, so you&#39;d probably need to have a convincing rationale =
for why it makes sense here.</div><div><br></div><div>On Tue, Oct 13, 2015 =
at 2:42 PM,=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:keith.f.kelly@gmai=
l.com" target=3D"_blank">keith.f.kelly@gmail.com</a>&gt;</span>=C2=A0wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>Referring back to my proposal, if an=
otherFunction() called base::Foo(), that wouldn&#39;t count as valid.=C2=A0=
 The point of the new specifier would be to require a direct literal call t=
o base::Foo() before every possible non-exceptional return path from the fu=
nction.</div></div></blockquote><div><br></div><div>This seems to be overly=
 restrictive, at least imo.=C2=A0</div></div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--089e0115f05244fa500522036739--

.

--001a11c266505cda6205220367dc
Content-Type: text/plain; charset=UTF-8

On 13 October 2015 at 22:45, <keith.f.kelly@gmail.com> wrote:

> On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:
>>
>> int Foo()
>> {
>>   if(SomeFunctionNotInCompilationUnit())
>>     return 5;
>>
>>   if(SomeFunctionNotInCompilationUnit2())
>>     return 10;
>> }
>>
>> Is this function legal or illegal? Well, it rather depends on what those
>> two functions return. But since the compiler cannot possibly see the
>> definition of those functions... it has no idea.
>>
>
> That sounds wrong.  The declaration/signature must be known by the
> compiler at that point, right?  Otherwise you'd get an "unknown symbol"
> error.  If the declaration/signatures is known, then the return type is
> known. If the return type is known, that's all you need to validate this
> function.
>
> It doesn't matter what each of those functions actually does. All that
> matters is that their declarations/signatures mean it's possible they could
> return 'false', which means this function doesn't return an int for every
> possible codepath. So it should be at least a warning if not an error.
>

so in that case should:

void Derived::foo()
{
  if (false) {
    Base::foo();
  }
}

just be a warning?

if not and SomeFunctionNotInCompilationUnit() is just 'return false' and
link time optimization allows that to be inlined should the unknown warning
suddenly change to a 'i know it's not possible' hard error?

should lto inlining be banned because it is now possible to change the
behavior?

--

---
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/.

--001a11c266505cda6205220367dc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 13 October 2015 at 22:45,  <span dir=3D"ltr">&lt;<a href=3D"mailto:k=
eith.f.kelly@gmail.com" target=3D"_blank">keith.f.kelly@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>int Foo()<br>{=
<br>=C2=A0 if(SomeFunctionNotInCompilationUnit())<br>=C2=A0=C2=A0=C2=A0 ret=
urn 5;<br><br>=C2=A0 if(SomeFunctionNotInCompilationUnit2())<br>=C2=A0=C2=
=A0=C2=A0 return 10;<br>}<br>=C2=A0<br>Is this function legal or illegal? W=
ell, it rather depends on what those two functions return. But since the co=
mpiler cannot possibly see the definition of those functions... it has no i=
dea.<br></div></div></blockquote><div><br></div></span><div>That sounds wro=
ng.=C2=A0 The declaration/signature must be known by the compiler at that p=
oint, right?=C2=A0 Otherwise you&#39;d get an &quot;unknown symbol&quot; er=
ror.=C2=A0 If the declaration/signatures is known, then the return type is =
known. If the return type is known, that&#39;s all you need to validate thi=
s function.</div><div><br></div><div>It doesn&#39;t matter what each of tho=
se functions actually does. All that matters is that their declarations/sig=
natures mean it&#39;s possible they could return &#39;false&#39;, which mea=
ns this function doesn&#39;t return an int for every possible codepath. So =
it should be at least a warning if not an error.</div></div></blockquote><d=
iv><br></div><div>so in that case should:<br><br></div><div>void Derived::f=
oo()<br>{<br></div><div>=C2=A0 if (false) { <br></div></div>=C2=A0=C2=A0=C2=
=A0 Base::foo();<br>=C2=A0 }<br>}<br><br></div><div class=3D"gmail_extra">j=
ust be a warning?<br><br></div><div class=3D"gmail_extra">if not and SomeFu=
nctionNotInCompilationUnit() is just &#39;return false&#39; and link time o=
ptimization allows that to be inlined should the unknown warning suddenly c=
hange to a &#39;i know it&#39;s not possible&#39; hard error? <br><br>shoul=
d lto inlining be banned because it is now possible to change the behavior?=
<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11c266505cda6205220367dc--

.

------=_Part_7756_1100599026.1444772917769
Content-Type: multipart/alternative;
 boundary="----=_Part_7757_1592554899.1444772917769"

------=_Part_7757_1592554899.1444772917769
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:38:02 PM UTC-7, Matt Calabrese wrote:
>
> No they don't. Foo doesn't have to be A or B.
>

Ah, yes, good call.  Then the function should be ill-formed.

--

---
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/.

------=_Part_7757_1592554899.1444772917769
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:38:02 PM UTC-7, Matt Cal=
abrese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div>No they don&#39;t. Foo doesn&#39;t hav=
e to be A or B.</div></div></div></div></blockquote><div><br></div><div>Ah,=
 yes, good call. =C2=A0Then the function should be ill-formed.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7757_1592554899.1444772917769--
------=_Part_7756_1100599026.1444772917769--

.

------=_Part_7984_52049521.1444773175113
Content-Type: multipart/alternative;
 boundary="----=_Part_7985_862118782.1444773175114"

------=_Part_7985_862118782.1444773175114
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:32:56 PM UTC-7, Sam Kellett wrote:
>
> sorry if i've missed you mentioning this is another post, but just out of
> interest -- what's wrong with this method?
>

Nothing's wrong with it.  The problem is that many frameworks (such as Qt)
just aren't implemented that way.

--

---
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/.

------=_Part_7985_862118782.1444773175114
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:32:56 PM UTC-7, Sam Kell=
ett wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>sorry if i&#39;ve missed you mentioning this is another post, but just ou=
t of interest -- what&#39;s wrong with this method?</div></div></blockquote=
><div><br></div><div>Nothing&#39;s wrong with it. =C2=A0The problem is that=
 many frameworks (such as Qt) just aren&#39;t implemented that way.=C2=A0</=
div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7985_862118782.1444773175114--
------=_Part_7984_52049521.1444773175113--

.

------=_Part_7961_1755280986.1444773252615
Content-Type: multipart/alternative;
 boundary="----=_Part_7962_1595866069.1444773252615"

------=_Part_7962_1595866069.1444773252615
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:33:46 PM UTC-7, dgutson wrote:
>
> even something like:
>
> const auto x = Base::foo(f);
> return x + 1;
> is it OK?
>

Yes, because there's only one non-exceptional return path and Base::foo()
is always called along that path.

--

---
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/.

------=_Part_7962_1595866069.1444773252615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:33:46 PM UTC-7, dgutson =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">even something like:
<br>
<br>const auto x =3D Base::foo(f);
<br>return x + 1;
<br>is it OK?<br></blockquote><div><br>Yes, because there&#39;s only one no=
n-exceptional return path and Base::foo() is always called along that path.=
=C2=A0</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7962_1595866069.1444773252615--
------=_Part_7961_1755280986.1444773252615--

.

This is a multi-part message in MIME format.
--------------080208030307000208050204
Content-Type: text/plain; charset=UTF-8; format=flowed



Am 13.10.2015 um 23:16 schrieb Nicol Bolas:
> On Tuesday, October 13, 2015 at 5:01:21 PM UTC-4, keith....@gmail.com
> wrote:
>
>     On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke
>     wrote:
>
>         No, it can't. *Some* compilers can attempt to solve this
>         problem with a
>         low rate of false positives, and even that is *hard*.
>         Proposing to
>         require that *every* conforming compiler must do so
>         *perfectly* is not
>         likely to go over well.
>
>     Every C++ compiler I've ever encountered will produce an error if
>     you write a function like this, because not every execution path
>     returns a value, and the function signatures requires that the
>     function return a value.
>
>
> Not this one. <http://ideone.com/frIFM6>
>
> Oh, it produces a /warning/. But unless you're compiling warnings as
> errors, those are two different things.
Whether it's a warning or error is irrelevant to the question of whether
the compiler was able to detect the condition.
Whether it's a warning or error only depends on what the standard
wording ends up being for this feature.

This whole argumentation of whether the compiler can detect a missing
return is a straw man and unrelated to this proposal. Fact is the
compiler can use a DFS over the CFG to see exactly how many times a
function is directly called (no transitive calls) for every single
control flow path through the function modulo exceptions. This is *not*
a hard problem.

Whether this feature has enough justification is an entirely different
issue and I am impartial to that. Just wanted to clarify some
misconceptions.

--

---
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/.

--------------080208030307000208050204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <br>
    <br>
    <div class=3D"moz-cite-prefix">Am 13.10.2015 um 23:16 schrieb Nicol
      Bolas:<br>
    </div>
    <blockquote
      cite=3D"mid:c6ef73ac-bce3-48a5-b6b8-570c0cfb7bfa@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Tuesday, October 13, 2015 at 5:01:21 PM UTC-4,
        <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:keith....@gmai=
l.com">keith....@gmail.com</a> wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div dir=3D"ltr">On Tuesday, October 13, 2015 at 1:30:00 PM
            UTC-7, Matthew Woehlke wrote:
            <blockquote class=3D"gmail_quote"
              style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
              solid;padding-left:1ex">No, it can't. *Some* compilers can
              attempt to solve this problem with a
              <br>
              low rate of false positives, and even that is *hard*.
              Proposing to
              <br>
              require that *every* conforming compiler must do so
              *perfectly* is not
              <br>
              likely to go over well.
              <br>
            </blockquote>
            <div>=C2=A0</div>
            <div>Every C++ compiler I've ever encountered will produce
              an error if you write a function like this, because not
              every execution path returns a value, and the function
              signatures requires that the function return a value.</div>
          </div>
        </blockquote>
        <div><br>
          <a moz-do-not-send=3D"true" href=3D"http://ideone.com/frIFM6">Not
            this one.</a><br>
          <br>
          Oh, it produces a <i>warning</i>. But unless you're compiling
          warnings as errors, those are two different things.<br>
        </div>
      </div>
    </blockquote>
    Whether it's a warning or error is irrelevant to the question of
    whether the compiler was able to detect the condition.<br>
    Whether it's a warning or error only depends on what the standard
    wording ends up being for this feature.<br>
    <br>
    This whole argumentation of whether the compiler can detect a
    missing return is a straw man and unrelated to this proposal. Fact
    is the compiler can use a DFS over the CFG to see exactly how many
    times a function is directly called (no transitive calls) for every
    single control flow path through the function modulo exceptions.
    This is *not* a hard problem.<br>
    <br>
    Whether this feature has enough justification is an entirely
    different issue and I am impartial to that. Just wanted to clarify
    some misconceptions.<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--------------080208030307000208050204--

.

------=_Part_8380_2057904264.1444773370575
Content-Type: multipart/alternative;
 boundary="----=_Part_8381_1057533573.1444773370589"

------=_Part_8381_1057533573.1444773370589
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 2:48:20 PM UTC-7, Sam Kellett wrote:
>
> so in that case should:
>
> void Derived::foo()
> {
>   if (false) {
>     Base::foo();
>   }
> }
>
> just be a warning?
>

I'd prefer for it to be an error, but if it's at least a warning so I can
enable "treat warnings as errors", then I'd be happy.

>
> if not and SomeFunctionNotInCompilationUnit() is just 'return false' and
> link time optimization allows that to be inlined should the unknown warning
> suddenly change to a 'i know it's not possible' hard error?
>
> should lto inlining be banned because it is now possible to change the
> behavior?
>

--

---
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/.

------=_Part_8381_1057533573.1444773370589
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 2:48:20 PM UTC-7, Sam Kell=
ett wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote"><div>so in that case should:<br><br></div><div=
>void Derived::foo()<br>{<br></div><div>=C2=A0 if (false) { <br></div></div=
>=C2=A0=C2=A0=C2=A0 Base::foo();<br>=C2=A0 }<br>}<br><br></div><div>just be=
 a warning?<br></div></div></blockquote><div><br></div><div>I&#39;d prefer =
for it to be an error, but if it&#39;s at least a warning so I can enable &=
quot;treat warnings as errors&quot;, then I&#39;d be happy.=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><d=
iv>if not and SomeFunctionNotInCompilationUn<wbr>it() is just &#39;return f=
alse&#39; and link time optimization allows that to be inlined should the u=
nknown warning suddenly change to a &#39;i know it&#39;s not possible&#39; =
hard error? <br><br>should lto inlining be banned because it is now possibl=
e to change the behavior?<br></div></div>
</blockquote></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_8381_1057533573.1444773370589--
------=_Part_8380_2057904264.1444773370575--

.

On Tuesday 13 October 2015 14:45:06 keith.f.kelly@gmail.com wrote:
> On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:
> > int Foo()
> > {
> >   if(SomeFunctionNotInCompilationUnit())
> >     return 5;
> >
> >   if(SomeFunctionNotInCompilationUnit2())
> >     return 10;
> > }
> >
> > Is this function legal or illegal? Well, it rather depends on what those
> > two functions return. But since the compiler cannot possibly see the
> > definition of those functions... it has no idea.
>
> That sounds wrong.  The declaration/signature must be known by the compiler
> at that point, right?  Otherwise you'd get an "unknown symbol" error.  If
> the declaration/signatures is known, then the return type is known. If the
> return type is known, that's all you need to validate this function.

You're mixing a lot of concepts here.

First of all, the declaration and signature of
SomeFunctionNotInCompilationUnit{,2} are known. The compiler does know those
functions exist. And the return type of those two functions must be something
that is convertible to boolean, otherwise we'd get a compilation error.

But the compiler does not know anything beyond that. It does not know when
each function returns a true value. It's entirely possible that the first
function always returns true, in which case the second call is actually dead
code and will never be executed.

Or, like Nicol said, it's possible that the two functions are constructed in
such a way that at least one of them will always return true. In that case,
the function Foo is perfectly valid and always returns a valid int. There's
nothing illegal or ill-formed about the code.

> It doesn't matter what each of those functions actually does. All that
> matters is that their declarations/signatures mean it's possible they could
> return 'false', which means this function doesn't return an int for every
> possible codepath. So it should be at least a warning if not an error.

It actually does matter what the functions do and that's the entire point.
Since the compiler cannot know what they do, it cannot assume that the code is
invalid. Therefore, the compiler *must* allow the code to be compiled.

Now, it may print a warning saying that your code is ugly and bad practice. I
agree. Personally, I wouldn't write code like that. Code is read more often
than it's written, so it's important that someone reading the code can
understand what happens. So it's probably better to write:

int Foo()
{
  if(SomeFunctionNotInCompilationUnit())
    return 5;

  SomeFunctionNotInCompilationUnit2();
  return 10;
}

or

int Foo()
{
  if(SomeFunctionNotInCompilationUnit())
    return 5;

  if(SomeFunctionNotInCompilationUnit2())
    return 10;
  assert(false);
}

But turning warnings into errors is an opt-in choice. The compiler cannot by
default reject the original code.

--
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

--

---
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 Tuesday 13 October 2015 22:32:54 Sam Kellett wrote:
> sorry if i've missed you mentioning this is another post, but just out of
> interest -- what's wrong with this method?
>
> you could even extend it if you wanted to give the user more control:
>
> class foo {
> public:
>   void key_press() { before_key_press(); do_base_class_stuff();
> after_key_press(); }
>
> private:
>   virtual void before_key_press() {}
>   virtual void after_key_press() {}
> };

See Matthew's reply earlier in this thread: because sometimes you *want* to
swallow the event. You don't want the base class to execute at all.

Real world example:

void QCalendarWidget::keyPressEvent(QKeyEvent * event)
{
    Q_D(QCalendarWidget);
    if (d->yearEdit->isVisible()&& event->matches(QKeySequence::Cancel)) {
        d->yearEdit->setValue(yearShown());
        d->_q_yearEditingFinished();
        return;
    }
    QWidget::keyPressEvent(event);
}

There's one code path that *explicitly* does not want to call the base class.

So even if we get a keyword or an attribute for this type of virtual override,
Qt will not use it.

--
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

--

---
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 Tuesday 13 October 2015 12:57:01 keith.f.kelly@gmail.com wrote:
> Why not?  It can already prove that not every path returns a value; isn't
> that solving the same problem?

It can't prove that. There are lots of false positives that people usually
work around.

--
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

--

---
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/.

.

--001a11c2578a995467052203c142
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 3:01 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Tuesday 13 October 2015 14:45:06 keith.f.kelly@gmail.com wrote:
> > On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:
> > > int Foo()
> > > {
> > >   if(SomeFunctionNotInCompilationUnit())
> > >     return 5;
> > >
> > >   if(SomeFunctionNotInCompilationUnit2())
> > >     return 10;
> > > }
> > >
> > > Is this function legal or illegal? Well, it rather depends on what
> those
> > > two functions return. But since the compiler cannot possibly see the
> > > definition of those functions... it has no idea.
> >
> > That sounds wrong.  The declaration/signature must be known by the
> compiler
> > at that point, right?  Otherwise you'd get an "unknown symbol" error.  If
> > the declaration/signatures is known, then the return type is known. If
> the
> > return type is known, that's all you need to validate this function.
>
> You're mixing a lot of concepts here.
>
> First of all, the declaration and signature of
> SomeFunctionNotInCompilationUnit{,2} are known. The compiler does know
> those
> functions exist. And the return type of those two functions must be
> something
> that is convertible to boolean, otherwise we'd get a compilation error.
>
> But the compiler does not know anything beyond that. It does not know when
> each function returns a true value. It's entirely possible that the first
> function always returns true, in which case the second call is actually
> dead
> code and will never be executed.


Notably, a standard way for developers to explicitly specify locations in
code as unreachable would make full, static checking more feasible (relying
on the user only marking *truly* unreachable locations as unreachable), but
otherwise, such checking would necessarily be overly restrictive. This is
especially important when your function's return type is something like a
reference type, or is otherwise difficult to provide some dummy fallback
return value for return statements in technically unreachable branches of
your code.

--

---
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/.

--001a11c2578a995467052203c142
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 3:01 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On Tues=
day 13 October 2015 14:45:06 <a href=3D"mailto:keith.f.kelly@gmail.com">kei=
th.f.kelly@gmail.com</a> wrote:<br>
&gt; On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:<b=
r>
&gt; &gt; int Foo()<br>
&gt; &gt; {<br>
&gt; &gt;=C2=A0 =C2=A0if(SomeFunctionNotInCompilationUnit())<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0return 5;<br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 =C2=A0if(SomeFunctionNotInCompilationUnit2())<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0return 10;<br>
&gt; &gt; }<br>
&gt; &gt;<br>
&gt; &gt; Is this function legal or illegal? Well, it rather depends on wha=
t those<br>
&gt; &gt; two functions return. But since the compiler cannot possibly see =
the<br>
&gt; &gt; definition of those functions... it has no idea.<br>
&gt;<br>
&gt; That sounds wrong.=C2=A0 The declaration/signature must be known by th=
e compiler<br>
&gt; at that point, right?=C2=A0 Otherwise you&#39;d get an &quot;unknown s=
ymbol&quot; error.=C2=A0 If<br>
&gt; the declaration/signatures is known, then the return type is known. If=
 the<br>
&gt; return type is known, that&#39;s all you need to validate this functio=
n.<br>
<br>
</span>You&#39;re mixing a lot of concepts here.<br>
<br>
First of all, the declaration and signature of<br>
SomeFunctionNotInCompilationUnit{,2} are known. The compiler does know thos=
e<br>
functions exist. And the return type of those two functions must be somethi=
ng<br>
that is convertible to boolean, otherwise we&#39;d get a compilation error.=
<br>
<br>
But the compiler does not know anything beyond that. It does not know when<=
br>
each function returns a true value. It&#39;s entirely possible that the fir=
st<br>
function always returns true, in which case the second call is actually dea=
d<br>
code and will never be executed.</blockquote><div><br></div><div>Notably, a=
 standard way for developers to explicitly specify locations in code as unr=
eachable would make full, static checking more feasible (relying on the use=
r only marking <i>truly</i>=C2=A0unreachable locations as unreachable), but=
 otherwise, such checking would necessarily be overly restrictive. This is =
especially important when your function&#39;s return type is something like=
 a reference type, or is otherwise difficult to provide some dummy fallback=
 return value for return statements in technically unreachable branches of =
your code.</div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11c2578a995467052203c142--

.

------=_Part_3095_394533464.1444775092256
Content-Type: multipart/alternative;
 boundary="----=_Part_3096_1859934109.1444775092256"

------=_Part_3096_1859934109.1444775092256
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 3:01:38 PM UTC-7, Thiago Macieira wrote:
>
> But turning warnings into errors is an opt-in choice. The compiler cannot
> by
> default reject the original code.


That's all fine.  I'd just like at least a warning which I can then choose
to treat as an error.  As things stand now, there's no way to surface these
kinds of defects at compile time, and there really needs to be, as it's a
common type of defect.

--

---
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/.

------=_Part_3096_1859934109.1444775092256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 3:01:38 PM UTC-7, Thiago M=
acieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">But turning warn=
ings into errors is an opt-in choice. The compiler cannot by=20
<br>default reject the original code.=C2=A0</blockquote><div><br></div><div=
>That&#39;s all fine. =C2=A0I&#39;d just like at least a warning which I ca=
n then choose to treat as an error. =C2=A0As things stand now, there&#39;s =
no way to surface these kinds of defects at compile time, and there really =
needs to be, as it&#39;s a common type of defect.</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3096_1859934109.1444775092256--
------=_Part_3095_394533464.1444775092256--

.

------=_Part_644_1647112476.1444775405492
Content-Type: multipart/alternative;
 boundary="----=_Part_645_1923499054.1444775405492"

------=_Part_645_1923499054.1444775405492
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 5:45:06 PM UTC-4, keith....@gmail.com wrote:
>
> On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:
>>
>> int Foo()
>> {
>>   if(SomeFunctionNotInCompilationUnit())
>>     return 5;
>>
>>   if(SomeFunctionNotInCompilationUnit2())
>>     return 10;
>> }
>>
>> Is this function legal or illegal? Well, it rather depends on what those
>> two functions return. But since the compiler cannot possibly see the
>> definition of those functions... it has no idea.
>>
>
> That sounds wrong.
>

Whether it sounds wrong or not is irrelevant. That's what the Standard for
Programming Language C++ says about return statements, and that's what
compilers do. That code is valid, legal C++, and a compiler *must* accept
this (compiler switches aside). And it will have well-defined behavior...
so long as one or the other of those functions returns something non-false.


> So it should be at least a warning if not an error.
>

Yes, compilers are allowed to issue warnings for this rather dubious code.
But they are not *required* to do so, nor are they allowed to *reject* this
code (again, compiler switches aside).

--

---
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/.

------=_Part_645_1923499054.1444775405492
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 5:45:06 PM UTC-4, keith...=
..@gmail.com wrote:<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">On Tuesday, October 13, 2015 at 2:16:14 PM UTC-7, Nicol Bolas wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>int Foo()<br>{<=
br>=C2=A0 if(<wbr>SomeFunctionNotInCompilationUn<wbr>it())<br>=C2=A0=C2=A0=
=C2=A0 return 5;<br><br>=C2=A0 if(<wbr>SomeFunctionNotInCompilationUn<wbr>i=
t2())<br>=C2=A0=C2=A0=C2=A0 return 10;<br>}<br>=C2=A0<br>Is this function l=
egal or illegal? Well, it rather depends on what those two functions return=
.. But since the compiler cannot possibly see the definition of those functi=
ons... it has no idea.<br></div></div></blockquote><div><br></div><div>That=
 sounds wrong.</div></div></blockquote><div><br>Whether it sounds wrong or =
not is irrelevant. That&#39;s what the Standard for Programming Language C+=
+ says about return statements, and that&#39;s what compilers do. That code=
 is valid, legal C++, and a compiler <i>must</i> accept this (compiler swit=
ches aside). And it will have well-defined behavior... so long as one or th=
e other of those functions returns something non-false.<br>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>S=
o it should be at least a warning if not an error.=C2=A0</div></div></block=
quote><div><br>Yes, compilers are allowed to issue warnings for this rather=
 dubious code. But they are not <i>required</i> to do so, nor are they allo=
wed to <i>reject</i> this code (again, compiler switches aside).<br></div><=
/div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_645_1923499054.1444775405492--
------=_Part_644_1647112476.1444775405492--

.

------=_Part_7864_618266403.1444775634720
Content-Type: multipart/alternative;
 boundary="----=_Part_7865_1862047245.1444775634720"

------=_Part_7865_1862047245.1444775634720
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 3:30:05 PM UTC-7, Nicol Bolas wrote:
>
> Yes, compilers are allowed to issue warnings for this rather dubious code.
> But they are not *required* to do so, nor are they allowed to *reject*
> this code (again, compiler switches aside).
>

Well, again, that's all fine.  It doesn't negate the fundamental proposal
-- that adding a specifier would then afford the ability to have some
compile-time validation.

--

---
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/.

------=_Part_7865_1862047245.1444775634720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 3:30:05 PM UTC-7, Nicol Bo=
las wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>Yes, compilers are allowed to issue warnings for this rather dubious code=
.. But they are not <i>required</i> to do so, nor are they allowed to <i>rej=
ect</i> this code (again, compiler switches aside).<br></div></div></blockq=
uote><div><br></div><div>Well, again, that&#39;s all fine. =C2=A0It doesn&#=
39;t negate the fundamental proposal -- that adding a specifier would then =
afford the ability to have some compile-time validation.=C2=A0</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_7865_1862047245.1444775634720--
------=_Part_7864_618266403.1444775634720--

.

------=_Part_6456_1328006536.1444776094709
Content-Type: multipart/alternative;
 boundary="----=_Part_6457_265520231.1444776094710"

------=_Part_6457_265520231.1444776094710
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 5:55:06 PM UTC-4, Miro Knejp wrote:
>
> Am 13.10.2015 um 23:16 schrieb Nicol Bolas:
>
> On Tuesday, October 13, 2015 at 5:01:21 PM UTC-4, keith....@gmail.com
> wrote:
>>
>> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:
>>>
>>> No, it can't. *Some* compilers can attempt to solve this problem with a
>>> low rate of false positives, and even that is *hard*. Proposing to
>>> require that *every* conforming compiler must do so *perfectly* is not
>>> likely to go over well.
>>>
>>
>> Every C++ compiler I've ever encountered will produce an error if you
>> write a function like this, because not every execution path returns a
>> value, and the function signatures requires that the function return a
>> value.
>>
>
> Not this one. <http://ideone.com/frIFM6>
>
> Oh, it produces a *warning*. But unless you're compiling warnings as
> errors, those are two different things.
>
> Whether it's a warning or error is irrelevant to the question of whether
> the compiler was able to detect the condition.
> Whether it's a warning or error only depends on what the standard wording
> ends up being for this feature.
>
> This whole argumentation of whether the compiler can detect a missing
> return is a straw man and unrelated to this proposal.
>

No, it is not. Keith *specifically* stated that he wanted his feature to
work like return. But once he explained what behavior he wanted, we had to
explain to him that return doesn't work that way.

So it's not a strawman of any kind; he specifically brought it up.

--

---
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/.

------=_Part_6457_265520231.1444776094710
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, October 13, 2015 at 5:55:06 PM UTC-4, Miro Knejp wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">Am 13.10.2015 um 23:16 schrieb =
Nicol
      Bolas:<br>
   =20
    <blockquote type=3D"cite">
      <div dir=3D"ltr">On Tuesday, October 13, 2015 at 5:01:21 PM UTC-4,
        <a>keith....@gmail.com</a> wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir=3D"ltr">On Tuesday, October 13, 2015 at 1:30:00 PM
            UTC-7, Matthew Woehlke wrote:
            <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">No, it can&#39;t. *Some=
* compilers can
              attempt to solve this problem with a
              <br>
              low rate of false positives, and even that is *hard*.
              Proposing to
              <br>
              require that *every* conforming compiler must do so
              *perfectly* is not
              <br>
              likely to go over well.
              <br>
            </blockquote>
            <div>=C2=A0</div>
            <div>Every C++ compiler I&#39;ve ever encountered will produce
              an error if you write a function like this, because not
              every execution path returns a value, and the function
              signatures requires that the function return a value.</div>
          </div>
        </blockquote>
        <div><br>
          <a href=3D"http://ideone.com/frIFM6" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3=
A%2F%2Fideone.com%2FfrIFM6\46sa\75D\46sntz\0751\46usg\75AFQjCNGXnRwCiEU_aom=
sOFhG0D7uQNE5RQ&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.g=
oogle.com/url?q\75http%3A%2F%2Fideone.com%2FfrIFM6\46sa\75D\46sntz\0751\46u=
sg\75AFQjCNGXnRwCiEU_aomsOFhG0D7uQNE5RQ&#39;;return true;">Not
            this one.</a><br>
          <br>
          Oh, it produces a <i>warning</i>. But unless you&#39;re compiling
          warnings as errors, those are two different things.<br>
        </div>
      </div>
    </blockquote>
    Whether it&#39;s a warning or error is irrelevant to the question of
    whether the compiler was able to detect the condition.<br>
    Whether it&#39;s a warning or error only depends on what the standard
    wording ends up being for this feature.<br>
    <br>
    This whole argumentation of whether the compiler can detect a
    missing return is a straw man and unrelated to this proposal.</div></bl=
ockquote><div><br>No, it is not. Keith <i>specifically</i> stated that he w=
anted his feature to work like return. But once he explained what behavior =
he wanted, we had to explain to him that return doesn&#39;t work that way.<=
br><br>So it&#39;s not a strawman of any kind; he specifically brought it u=
p.</div><br>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_6457_265520231.1444776094710--
------=_Part_6456_1328006536.1444776094709--

.

--001a11411418f5364a05220507c5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 13, 2015 at 2:39 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Am 13.10.2015 um 23:24 schrieb Matthew Woehlke:
>
>> On 2015-10-13 16:56, keith.f.kelly@gmail.com wrote:
>>
>>> Sorry, but I don't know what you mean by "top post".
>>>
>> https://en.wikipedia.org/wiki/Posting_style#Top-posting
>>
>> (BTW, gmail's interface is junk; that's why I use thunderbird and
>> news://news.gmane.org/gmane.comp.lang.c++.isocpp.proposals ;-).)
>>
>> On 2015-10-13 17:01, keith.f.kelly@gmail.com wrote:
>>
>>> On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote=
:
>>>
>>>> No, it can't. *Some* compilers can attempt to solve this problem with =
a
>>>> low rate of false positives, and even that is *hard*. Proposing to
>>>> require that *every* conforming compiler must do so *perfectly* is not
>>>> likely to go over well.
>>>>
>>>   Every C++ compiler I've ever encountered will produce an error if you
>>> write
>>> a function like this,
>>>
>> Really? I've yet to encounter a single one. (I'm taking your wording
>> "will" literally, as in "by default". Which, much as I wish otherwise,
>> is not the case.)
>>
>> because not every execution path returns a value, and
>>> the function signatures requires that the function return a value. Are
>>> you
>>> saying not all compilers will error on this kind of programmer oversigh=
t?
>>>
>> Have you used any compiler other than GCC, Clang, MSVC and *possibly*
>> ICC? Because AFAIK this is a hard - if not impossible=C2=B9 - problem to
>> solve perfectly. Trying to enforce that on everyone that wants to write
>> their own compiler seems likely to meet with resistance.
>>
>> (=C2=B9 https://en.wikipedia.org/wiki/Halting_problem)
>>
> This is unrelated to the halting problem. Every compiler worth its salt
> has to produce some form of control flow graph which makes it trivial to
> detect whether all paths to leaf nodes have a certain property with a pla=
in
> DSF from the function entry point. This is not rocket science. The OP has
> stated that he is interested only in direct calls to the base
> implementation, not accounting for transitive calls.
>
>>
>> I'm not familiar with compiler design but it would seem to me to be a
>>> trivial thing to prove that every way of returning from this function
>>> actually returned an int.
>>>
>> Let's pretend this is an override of an "extendable" method:
>>
>>    enum Foo { A, B };
>>    int Derived::foo(Foo f)
>>    {
>>      switch (f)
>>      {
>>        case A:
>>          return 1 + Base::foo(f);
>>        case B:
>>          return 2 + Base::foo(f);
>>      }
>>    }
>>
>> I expect you'd have a hard time convincing the committee to make that
>> ill-formed... either due to your proposal, or simply because it "doesn't
>> always return a value".
>>
>> "extendable" or not, this function has UB because an enum can have *any*
> value of the underlying type.


That's not true; please read [dcl.enum]/8 and [expr.static.cast]/10 in the
current working draft for the complete set of rules. In the above case, the
values of the enumeration Foo are in the range [0, 2), and there is no way
to create any other value without invoking undefined behavior. Both Clang
and GCC support optimizing on the basis of this rule via the -fstrict-enums
flag.

The compiler has to assume the switch does not hit any case. There is an
> edge in the CFG from the entry point to the end of the function that does
> not contain a return.
>
>
> --
>
> --- 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/.
>

--=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/.

--001a11411418f5364a05220507c5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 2:39 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div c=
lass=3D"h5">Am <a href=3D"tel:13.10.2015" value=3D"+13102015" target=3D"_bl=
ank">13.10.2015</a> um 23:24 schrieb Matthew Woehlke:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 2015-10-13 16:56, <a href=3D"mailto:keith.f.kelly@gmail.com" target=3D"_=
blank">keith.f.kelly@gmail.com</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Sorry, but I don&#39;t know what you mean by &quot;top post&quot;.<br>
</blockquote>
<a href=3D"https://en.wikipedia.org/wiki/Posting_style#Top-posting" rel=3D"=
noreferrer" target=3D"_blank">https://en.wikipedia.org/wiki/Posting_style#T=
op-posting</a><br>
<br>
(BTW, gmail&#39;s interface is junk; that&#39;s why I use thunderbird and<b=
r>
news://<a href=3D"http://news.gmane.org/gmane.comp.lang.c++.isocpp.proposal=
s" rel=3D"noreferrer" target=3D"_blank">news.gmane.org/gmane.comp.lang.c++.=
isocpp.proposals</a> ;-).)<br>
<br>
On 2015-10-13 17:01, <a href=3D"mailto:keith.f.kelly@gmail.com" target=3D"_=
blank">keith.f.kelly@gmail.com</a> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Tuesday, October 13, 2015 at 1:30:00 PM UTC-7, Matthew Woehlke wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
No, it can&#39;t. *Some* compilers can attempt to solve this problem with a=
<br>
low rate of false positives, and even that is *hard*. Proposing to<br>
require that *every* conforming compiler must do so *perfectly* is not<br>
likely to go over well.<br>
</blockquote>
=C2=A0 Every C++ compiler I&#39;ve ever encountered will produce an error i=
f you write<br>
a function like this,<br>
</blockquote>
Really? I&#39;ve yet to encounter a single one. (I&#39;m taking your wordin=
g<br>
&quot;will&quot; literally, as in &quot;by default&quot;. Which, much as I =
wish otherwise,<br>
is not the case.)<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
because not every execution path returns a value, and<br>
the function signatures requires that the function return a value. Are you<=
br>
saying not all compilers will error on this kind of programmer oversight?<b=
r>
</blockquote>
Have you used any compiler other than GCC, Clang, MSVC and *possibly*<br>
ICC? Because AFAIK this is a hard - if not impossible=C2=B9 - problem to<br=
>
solve perfectly. Trying to enforce that on everyone that wants to write<br>
their own compiler seems likely to meet with resistance.<br>
<br>
(=C2=B9 <a href=3D"https://en.wikipedia.org/wiki/Halting_problem" rel=3D"no=
referrer" target=3D"_blank">https://en.wikipedia.org/wiki/Halting_problem</=
a>)<br>
</blockquote></div></div>
This is unrelated to the halting problem. Every compiler worth its salt has=
 to produce some form of control flow graph which makes it trivial to detec=
t whether all paths to leaf nodes have a certain property with a plain DSF =
from the function entry point. This is not rocket science. The OP has state=
d that he is interested only in direct calls to the base implementation, no=
t accounting for transitive calls.<span class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I&#39;m not familiar with compiler design but it would seem to me to be a<b=
r>
trivial thing to prove that every way of returning from this function<br>
actually returned an int.<br>
</blockquote>
Let&#39;s pretend this is an override of an &quot;extendable&quot; method:<=
br>
<br>
=C2=A0 =C2=A0enum Foo { A, B };<br>
=C2=A0 =C2=A0int Derived::foo(Foo f)<br>
=C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0switch (f)<br>
=C2=A0 =C2=A0 =C2=A0{<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0case A:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 1 + Base::foo(f);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0case B:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 2 + Base::foo(f);<br>
=C2=A0 =C2=A0 =C2=A0}<br>
=C2=A0 =C2=A0}<br>
<br>
I expect you&#39;d have a hard time convincing the committee to make that<b=
r>
ill-formed... either due to your proposal, or simply because it &quot;doesn=
&#39;t<br>
always return a value&quot;.<br>
<br>
</blockquote></span>
&quot;extendable&quot; or not, this function has UB because an enum can hav=
e *any* value of the underlying type.</blockquote><div><br></div><div>That&=
#39;s not true; please read [dcl.enum]/8 and [expr.static.cast]/10 in the c=
urrent working draft for the complete set of rules. In the above case, the =
values of the enumeration Foo are in the range [0, 2), and there is no way =
to create any other value without invoking undefined behavior. Both Clang a=
nd GCC support optimizing on the basis of this rule via the -fstrict-enums =
flag.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The compiler has t=
o assume the switch does not hit any case. There is an edge in the CFG from=
 the entry point to the end of the function that does not contain a return.=
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11411418f5364a05220507c5--

.

--001a11c2feb227deb8052205144a
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 4:44 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
>
> That's not true; please read [dcl.enum]/8 and [expr.static.cast]/10 in the
> current working draft for the complete set of rules. In the above case, the
> values of the enumeration Foo are in the range [0, 2), and there is no way
> to create any other value without invoking undefined behavior. Both Clang
> and GCC support optimizing on the basis of this rule via the -fstrict-enums
> flag.
>

Ah, true, because it doesn't specify a fixed underlying type, there. Right?

--

---
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/.

--001a11c2feb227deb8052205144a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 4:44 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>That&#39;s not true; pleas=
e read [dcl.enum]/8 and [expr.static.cast]/10 in the current working draft =
for the complete set of rules. In the above case, the values of the enumera=
tion Foo are in the range [0, 2), and there is no way to create any other v=
alue without invoking undefined behavior. Both Clang and GCC support optimi=
zing on the basis of this rule via the -fstrict-enums flag.</div></div></di=
v></div></blockquote><div><br></div><div>Ah, true, because it doesn&#39;t s=
pecify a fixed underlying type, there. Right?</div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11c2feb227deb8052205144a--

.

--001a1143b1acb84e9e052206527d
Content-Type: text/plain; charset=UTF-8

On Tue, Oct 13, 2015 at 4:48 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Tue, Oct 13, 2015 at 4:44 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
>>
>> That's not true; please read [dcl.enum]/8 and [expr.static.cast]/10 in
>> the current working draft for the complete set of rules. In the above case,
>> the values of the enumeration Foo are in the range [0, 2), and there is no
>> way to create any other value without invoking undefined behavior. Both
>> Clang and GCC support optimizing on the basis of this rule via the
>> -fstrict-enums flag.
>>
>
> Ah, true, because it doesn't specify a fixed underlying type, there. Right?
>

Right.

Also relevant is that the number of enumerators in the example was a power
of two. Given:

enum E { A, B, C };
int f(E e) {
  switch (e) { case A: case B: case C: return 0; }
  return 1;
}

.... the "return 1;" is reachable if the value of e is 3.

--

---
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/.

--001a1143b1acb84e9e052206527d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 13, 2015 at 4:48 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><span class=3D"">On Tue, Oct 13, 2015 at 4:44=
 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.=
co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&gt;</span> wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div>That&#39;s not true; please read [dcl.enum]/8 and =
[expr.static.cast]/10 in the current working draft for the complete set of =
rules. In the above case, the values of the enumeration Foo are in the rang=
e [0, 2), and there is no way to create any other value without invoking un=
defined behavior. Both Clang and GCC support optimizing on the basis of thi=
s rule via the -fstrict-enums flag.</div></div></div></div></blockquote><di=
v><br></div></span><div>Ah, true, because it doesn&#39;t specify a fixed un=
derlying type, there. Right?</div></div></div></div></blockquote><div><br><=
/div><div>Right.</div><div><br></div><div>Also relevant is that the number =
of enumerators in the example was a power of two. Given:</div><div><br></di=
v><div>enum E { A, B, C };</div><div>int f(E e) {</div><div>=C2=A0 switch (=
e) { case A: case B: case C: return 0; }</div><div>=C2=A0 return 1;</div><d=
iv>}</div><div><br></div><div>... the &quot;return 1;&quot; is reachable if=
 the value of e is 3.</div></div></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a1143b1acb84e9e052206527d--

.

On 2015-10-13 17:39, Miro Knejp wrote:
>> AFAIK [determining if a function always returns "correctly"] is a
>> hard - if not impossible=C2=B9 - problem to solve perfectly. Trying to
>> enforce that on everyone that wants to write their own compiler
>> seems likely to meet with resistance.
>>=20
>> (=C2=B9 https://en.wikipedia.org/wiki/Halting_problem)
>
> This is unrelated to the halting problem. Every compiler worth its salt
> has to produce some form of control flow graph which makes it trivial to
> detect whether all paths to leaf nodes have a certain property with a
> plain DSF from the function entry point. This is not rocket science. The
> OP has stated that he is interested only in direct calls to the base
> implementation, not accounting for transitive calls.

Since it is perfectly trivial to accomplish, please tell me if this
function has UB:

  int foo()
  {
    if (fun1()) return1;
    if (fun2()) return2;
    fun3();
  }

Hint #1: As previously mentioned, (fun1() || fun2()) might always be true.

Hint #2: fun3() might never return, or might always throw an exception.

This function "looks" like it should be ill-formed, but the compiler
can't know that; it doesn't have enough information. It *can't* have
enough information... because, yes, this *is* (AFAICT) the halting
problem. Consider:

  while (!(fun1() || fun2()) {}

This is a specific formulation of a program with arbitrary instructions
(fun1, fun2), and of course arbitrary input, which per the theorem
cannot be solved in all cases. However, a compiler that can determine if
foo() will always return can also determine if the above halts.
Therefore (if the HP theorem is true), the compiler *cannot* reliably
determine, for all possibly fun1, fun2, if foo() always returns.

This is not to say that *some* cases can't be solved, just as there are
cases for which the halting problem can be solved. I'm not a compiler
writer to know whether or not solving medium-complexity cases is "easy",
but I suspect it's not as trivial as you make it sound (keep in mind I'm
considering the case of writing a compiler from scratch, *not* adding
Keith's feature to an existing compiler that already does CFG analysis).

>>> I'm not familiar with compiler design but it would seem to me to be a
>>> trivial thing to prove that every way of returning from this function
>>> actually returned an int.
>>
>> Let's pretend this is an override of an "extendable" method:
>>
>>    enum Foo { A, B };
>>    int Derived::foo(Foo f)
>>    {
>>      switch (f)
>>      {
>>        case A:
>>          return 1 + Base::foo(f);
>>        case B:
>>          return 2 + Base::foo(f);
>>      }
>>    }
>>
>> I expect you'd have a hard time convincing the committee to make that
>> ill-formed... either due to your proposal, or simply because it "doesn't
>> always return a value".
>
> "extendable" or not, this function has UB because an enum can have *any*
> value of the underlying type.

No it doesn't. It only has UB if the function *is actually called* with
a value other than A or B. Per above, you can't generally prove that
this ever actually happens; therefore, you are not justified requiring
the compiler to make the program ill-formed. My feel of the general
consensus in this area is that folks (myself included) object to making
code like the above ill-formed. (I would only be tolerant of doing so if
there was a way, that does not impact optimization, to tell the compiler
that a certain point in the code is expected to be unreachable, that
could be added to the above to make it well formed.)

--=20
Matthew

--=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/.

.

Am 14.10.2015 um 16:38 schrieb Matthew Woehlke:
> On 2015-10-13 17:39, Miro Knejp wrote:
>>> AFAIK [determining if a function always returns "correctly"] is a
>>> hard - if not impossible=C2=B9 - problem to solve perfectly. Trying to
>>> enforce that on everyone that wants to write their own compiler
>>> seems likely to meet with resistance.
>>>
>>> (=C2=B9 https://en.wikipedia.org/wiki/Halting_problem)
>> This is unrelated to the halting problem. Every compiler worth its salt
>> has to produce some form of control flow graph which makes it trivial to
>> detect whether all paths to leaf nodes have a certain property with a
>> plain DSF from the function entry point. This is not rocket science. The
>> OP has stated that he is interested only in direct calls to the base
>> implementation, not accounting for transitive calls.
> Since it is perfectly trivial to accomplish, please tell me if this
> function has UB:
>
>    int foo()
>    {
>      if (fun1()) return1;
>      if (fun2()) return2;
>      fun3();
>    }
>
> Hint #1: As previously mentioned, (fun1() || fun2()) might always be true=
..
>
> Hint #2: fun3() might never return, or might always throw an exception.
That's all besides the point. The CFG is constructed for all possible=20
static paths through the function.

Quotes from the OP:
* "I'm saying that every possible return path from the derived method=20
must call base::foo()."
* "I'm suggesting the compiler prove that a literal direct call to=20
foo::bar() appears in execution flow before every possible return path=20
from the function."
* "Yes, but not just anywhere. It must appear exactly once along each=20
execution path that leads to a return from the function."

As stated he wants the function to be ill-formed (not UB) if not all=20
control flow paths call the base implementation exactly once, without=20
accounting for transitive calls or exceptions. Detecting that property=20
is trivial: if not all possible and well-defined edge paths from the=20
entry point to every returning leaf node contain exactly one direct call=20
to the base implementation the function would be ill-formed under the=20
proposed semantics. That is not a hard problem but a basic exercise in=20
graph theory.

We can argue whether these semantics make sense or are desireable. I=20
don't really care either way. All I'm saying is the semantics as=20
proposed are realizable with known algorithms. You may not agree with=20
the proposed semantics but that doesn't affect the feasability of their=20
implementation.

> No it doesn't. It only has UB if the function *is actually called* with
> a value other than A or B.
Yes, Richard already corrected that. Thanks for repeating though :-)

--=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 2015-10-14 12:36, Miro Knejp wrote:
> Am 14.10.2015 um 16:38 schrieb Matthew Woehlke:
>> Since it is perfectly trivial to accomplish, please tell me if this
>> function has UB:
>>
>>    int foo()
>>    {
>>      if (fun1()) return1;
>>      if (fun2()) return2;
>>      fun3();
>>    }
>>
>> Hint #1: As previously mentioned, (fun1() || fun2()) might always be
>> true.
>>
>> Hint #2: fun3() might never return, or might always throw an exception.
>
> That's all besides the point. The CFG is constructed for all possible
> static paths through the function.

No, it isn't. My general impression is that folks object to making a
function ill-formed due to a code path that *cannot actually ever
execute*. And in particular, *I* object to that, which is the point I am
trying to make that you seem happy to ignore.

I object, strenuously, to the compiler forcing me to write code that I
*know* will never, ever execute. Moreover, as someone pointed out, I may
not even be *able to do so* in any reasonable fashion (e.g. returning a
reference).

That's like saying that a function must do something reasonable even if
its invariants have been violated. That's ridiculous. UB exists for a
reason.

> Quotes from the OP:
> * "I'm saying that every possible return path from the derived method
> must call base::foo()."
> * "I'm suggesting the compiler prove that a literal direct call to
> foo::bar() appears in execution flow before every possible return path
> from the function."
> * "Yes, but not just anywhere. It must appear exactly once along each
> execution path that leads to a return from the function."

You are conflating "possible" with "conceivable". They are not the same.

> As stated he wants the function to be ill-formed (not UB) if not all
> control flow paths call the base implementation exactly once,

And I'm saying: good luck with that.

--
Matthew

--

---
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/.

.

------=_Part_6820_1175944305.1444845062680
Content-Type: multipart/alternative;
 boundary="----=_Part_6821_574818835.1444845062680"

------=_Part_6821_574818835.1444845062680
Content-Type: text/plain; charset=UTF-8

On Tuesday, October 13, 2015 at 3:58:48 PM UTC-4, keith....@gmail.com wrote:
>
> To clarify, I'm not suggesting the compiler prove that every return path
> *results* in foo::bar() having been called indirectly by way of some other
> function call.  I'm suggesting the compiler prove that a literal direct
> call to foo::bar() appears in execution flow before every possible return
> path from the function.
>

OK, now that we've cleared up the question of whether `return` has the
behavior you want, we can ask an important question:

Would it be a good idea to give this `extendable` the behavior you desire?

My answer: no, it would not.

You explicitly state that the base class cannot be called by a
sub-function. Which means you can *never* refector any code that does the
call. You can't extract anything that leads to it or anything that comes
from it. If you take away that kind of abstraction, that leaves two
choices: the user can either not abstract their code, or they will use
macros.

Both choices are varying levels of bad.

Of course, once you take away that restriction, you make it impossible to
statically verify. So you've arrived at two bad choices: either your
feature does no checking (and thus doesn't exist), or your feature
encourages the writing of bad code.

And yet, this problem can easily be solved by you simply calling
preamble/postamble functions, as has been suggested here several times.
This worked in C++98/03, so it has no dependencies on them.

Then, there's just basic utility of the concept. So you've got a base class
function that you need to ensure is called. And you want to ensure this so
much that you want to statically check all possible control paths and error
if there is even one that doesn't call it.

So what does this code mean:

void derived::func()
{
  if(condition_that_happens_to_always_be_true)
  {
    //Stuff
    base::func();
    //Post-stuff
  }
}

Obviously, that won't work. Despite the fact that the conditional
expression will always be true, it won't compile. So now you have to do
this to shut the compiler up:

void derived::func()
{
  if(condition_that_happens_to_always_be_true)
  {
    //Stuff
    base::func();
    //Post-stuff
  }

  base::func();
}

Only now... that calls the base class function *twice*. So now you need to
do this:

void derived::func()
{
  if(condition_that_happens_to_always_be_true)
  {
    //Stuff
    base::func();
    //Post-stuff
    return;
  }

  base::func();
}

So just to shut the compiler up, I need to write two completely unnecessary
statements in what was otherwise perfectly valid code.

Not to mention, look at what happens when the logic gets complex:

void derived::func()
{
  //Processing before call
  if(stuff)
  {
    //Conditional processing before call.
    if(other_stuff)
    {
      //Double Conditional processing before call.
      base::func();
      //Double Conditional processing after call.
    }
  }

  base::func();
  //Required processing after call.
}

Oops: `base::func` can get called twice now. To avoid that, they have to
re-write their code like this:

void derived::func()
{
  //Processing before call
  if(stuff)
  {
    //Conditional processing before call.
    if(other_stuff)
    {
      //Double Conditional processing before call.
    }
  }

  base::func();

  if(stuff && other_stuff)
  {
      //Double Conditional processing after call.
  }

  //Processing after call.
}

That's the most effective way to structure this code and get around your
static requirements. It makes the logic harder to reason about, but at
least it works.

That looks suspiciously like:

void derived::func_preamble()
{
  //Processing before call
  if(stuff)
  {
    //Conditional processing before call.
    if(other_stuff)
    {
      //Double Conditional processing before call.
    }
  }
}

void derived::func_postamble()
{
  if(stuff && other_stuff)
  {
      //Double Conditional processing after call.
  }

  //Processing after call.
}

So if the user is going to have to effectively structure their code that
way *anyway*, why not just force them to do it properly?

--

---
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/.

------=_Part_6821_574818835.1444845062680
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 13, 2015 at 3:58:48 PM UTC-4, keith...=
..@gmail.com wrote:<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">To clarify, I&#39;m not suggesting the compiler prove that every retur=
n path *results* in foo::bar() having been called indirectly by way of some=
 other function call. =C2=A0I&#39;m suggesting the compiler prove that a li=
teral direct call to foo::bar() appears in execution flow before every poss=
ible return path from the function.</div></blockquote><div><br>OK, now that=
 we&#39;ve cleared up the question of whether `return` has the behavior you=
 want, we can ask an important question:<br><br>Would it be a good idea to =
give this `extendable` the behavior you desire?<br><br>My answer: no, it wo=
uld not.<br><br>You explicitly state that the base class cannot be called b=
y a sub-function. Which means you can <i>never</i> refector any code that d=
oes the call. You can&#39;t extract anything that leads to it or anything t=
hat comes from it. If you take away that kind of abstraction, that leaves t=
wo choices: the user can either not abstract their code, or they will use m=
acros.<br><br>Both choices are varying levels of bad.<br><br>Of course, onc=
e you take away that restriction, you make it impossible to statically veri=
fy. So you&#39;ve arrived at two bad choices: either your feature does no c=
hecking (and thus doesn&#39;t exist), or your feature encourages the writin=
g of bad code.<br><br>And yet, this problem can easily be solved by you sim=
ply calling preamble/postamble functions, as has been suggested here severa=
l times. This worked in C++98/03, so it has no dependencies on them.<br><br=
>Then, there&#39;s just basic utility of the concept. So you&#39;ve got a b=
ase class function that you need to ensure is called. And you want to ensur=
e this so much that you want to statically check all possible control paths=
 and error if there is even one that doesn&#39;t call it.<br><br>So what do=
es this code mean:<br><br>void derived::func()<br>{<br>=C2=A0 if(condition_=
that_happens_to_always_be_true)<br>=C2=A0 {<br>=C2=A0 =C2=A0 //Stuff<br>=C2=
=A0 =C2=A0 base::func();<br>=C2=A0 =C2=A0 //Post-stuff<br>=C2=A0 }<br>}<br>=
<br>Obviously, that won&#39;t work. Despite the fact that the conditional e=
xpression will always be true, it won&#39;t compile. So now you have to do =
this to shut the compiler up:<br><br>void derived::func()<br>{<br>=C2=A0 if=
(condition_that_happens_to_always_be_true)<br>=C2=A0 {<br>=C2=A0 =C2=A0 //S=
tuff<br>=C2=A0 =C2=A0 base::func();<br>=C2=A0 =C2=A0 //Post-stuff<br>=C2=A0=
 }<br><br>=C2=A0 base::func();<br>}<br><br>Only now... that calls the base =
class function <i>twice</i>. So now you need to do this:<br><br>void derive=
d::func()<br>{<br>=C2=A0 if(condition_that_happens_to_always_be_true)<br>=
=C2=A0 {<br>=C2=A0 =C2=A0 //Stuff<br>=C2=A0 =C2=A0 base::func();<br>=C2=A0 =
=C2=A0 //Post-stuff<br>=C2=A0 =C2=A0 return;<br>=C2=A0 }<br><br>=C2=A0 base=
::func();<br>}<br><br>So just to shut the compiler up, I need to write two =
completely unnecessary statements in what was otherwise perfectly valid cod=
e.<br><br>Not to mention, look at what happens when the logic gets complex:=
<br><br>void derived::func()<br>{<br>=C2=A0 //Processing before call<br>=C2=
=A0 if(stuff)<br>=C2=A0 {<br>=C2=A0 =C2=A0 //Conditional processing before =
call.<br>=C2=A0 =C2=A0 if(other_stuff)<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =
=C2=A0 //Double Conditional processing before call.<br>=C2=A0 =C2=A0 =C2=A0=
 base::func();<br>=C2=A0 =C2=A0 =C2=A0 //Double Conditional processing afte=
r call.<br>=C2=A0 =C2=A0 }<br>=C2=A0 }<br><br>=C2=A0 base::func();<br>=C2=
=A0 //Required processing after call.<br>}<br><br>Oops: `base::func` can ge=
t called twice now. To avoid that, they have to re-write their code like th=
is:<br><br>void derived::func()<br>{<br>=C2=A0 //Processing before call<br>=
=C2=A0 if(stuff)<br>=C2=A0 {<br>=C2=A0 =C2=A0 //Conditional processing befo=
re call.<br>=C2=A0 =C2=A0 if(other_stuff)<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=
=A0 =C2=A0 //Double Conditional processing before call.<br>=C2=A0 =C2=A0 }<=
br>=C2=A0 }<br><br>=C2=A0 base::func();<br><br>=C2=A0 if(stuff &amp;&amp; o=
ther_stuff)<br>=C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 //Double Conditional proces=
sing after call.<br>=C2=A0 }<br><br>=C2=A0 //Processing after call.<br>}<br=
><br>That&#39;s the most effective way to structure this code and get aroun=
d your static requirements. It makes the logic harder to reason about, but =
at least it works.<br><br>That looks suspiciously like:<br><br>void derived=
::func_preamble()<br>{<br>=C2=A0 //Processing before call<br>=C2=A0 if(stuf=
f)<br>=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 //Conditional processing before call.<=
br>=C2=A0=C2=A0=C2=A0 if(other_stuff)<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 //Double Conditional processing before call.<br>=C2=
=A0=C2=A0=C2=A0 }<br>=C2=A0 }<br>}<br><br>void derived::func_postamble()<br=
>{<br>=C2=A0 if(stuff &amp;&amp; other_stuff)<br>=C2=A0 {<br>=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 //Double Conditional processing after call.<br>=C2=A0 }<=
br><br>=C2=A0 //Processing after call.<br>}<br><br>So if the user is going =
to have to effectively structure their code that way <i>anyway</i>, why not=
 just force them to do it properly?<br></div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_6821_574818835.1444845062680--
------=_Part_6820_1175944305.1444845062680--

.

Am 14.10.2015 um 18:55 schrieb Matthew Woehlke:
> On 2015-10-14 12:36, Miro Knejp wrote:
>> Am 14.10.2015 um 16:38 schrieb Matthew Woehlke:
>>> Since it is perfectly trivial to accomplish, please tell me if this
>>> function has UB:
>>>
>>>     int foo()
>>>     {
>>>       if (fun1()) return1;
>>>       if (fun2()) return2;
>>>       fun3();
>>>     }
>>>
>>> Hint #1: As previously mentioned, (fun1() || fun2()) might always be
>>> true.
>>>
>>> Hint #2: fun3() might never return, or might always throw an exception.
>> That's all besides the point. The CFG is constructed for all possible
>> static paths through the function.
> No, it isn't. My general impression is that folks object to making a
> function ill-formed due to a code path that *cannot actually ever
> execute*. And in particular, *I* object to that, which is the point I am
> trying to make that you seem happy to ignore.
Sorry, but whether the proposed feature categorizes functions as
ill-formed or not has nothing to do with whether the compiler is capable
of constructing a CFG for all possible paths through a function and
analyze their properties as evidenced by actual compiler output. That is
what compilers do all the time. Every control flow statement generates
edges in the CFG for all possible outcomes, whether you like it or not.
That is the very foundation of the whole code transformation business.
You claimed it is a hard problem, I showed otherwise. At no point have I
argued in favor or against the proposed feature, I am merely telling
you, from a purely technical standpoint, that the feature as worded by
the OP is easily implementable, which was put into question. Period.
That's all I said.

Even your very own example demonstrates exactly that. The compiler must
assume that fun3 can be called and you can clearly see that in the
generated bytecode the second if branches off to a block with a trap
instruction where the return should have been, plus a friendly
diagnostic. Even the example with the switch over the enum class
generated a default case jump to a block with a trap after the
switch[*]. The compiler is very well aware under which exact conditions
those blocks can be reached and takes them into account, however it does
not produce a diagnostic in the latter case as the block can only be
reached via UB, and therefore it would also not be a candidate for the
OP's proposed feature. This is all front-end work. The optimizer then
takes advantage of this information and does its shenanigans under
as-if. When it comes to these issues I prefer to leave the philosophical
realm and look at how these tools actually work and what output they
actually produce. If you don't believe me just run the examples yourself.

[*] interestingly -fstrict-enums doesn't seem to have an effect in this
case under -O0 and -O1
>
> I object, strenuously, to the compiler forcing me to write code that I
> *know* will never, ever execute. Moreover, as someone pointed out, I may
> not even be *able to do so* in any reasonable fashion (e.g. returning a
> reference).
>
> That's like saying that a function must do something reasonable even if
> its invariants have been violated. That's ridiculous. UB exists for a
> reason.
>
>> Quotes from the OP:
>> * "I'm saying that every possible return path from the derived method
>> must call base::foo()."
>> * "I'm suggesting the compiler prove that a literal direct call to
>> foo::bar() appears in execution flow before every possible return path
>> from the function."
>> * "Yes, but not just anywhere. It must appear exactly once along each
>> execution path that leads to a return from the function."
> You are conflating "possible" with "conceivable". They are not the same.
Those are synonyms. Look it up.
>
>> As stated he wants the function to be ill-formed (not UB) if not all
>> control flow paths call the base implementation exactly once,
> And I'm saying: good luck with that.
>
Not my problem.

--

---
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/.

.

------=_Part_3933_2068134983.1444852461461
Content-Type: multipart/alternative;
 boundary="----=_Part_3934_687832138.1444852461461"

------=_Part_3934_687832138.1444852461461
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 14, 2015 at 10:51:02 AM UTC-7, Nicol Bolas wrote:
>
> On Tuesday, October 13, 2015 at 3:58:48 PM UTC-4, keith....@gmail.com
> wrote:
>>
>> To clarify, I'm not suggesting the compiler prove that every return path
>> *results* in foo::bar() having been called indirectly by way of some other
>> function call.  I'm suggesting the compiler prove that a literal direct
>> call to foo::bar() appears in execution flow before every possible return
>> path from the function.
>>
>
> OK, now that we've cleared up the question of whether `return` has the
> behavior you want, we can ask an important question:
>
> Would it be a good idea to give this `extendable` the behavior you desire?
>
> My answer: no, it would not.
>

All of your arguments assume I have the power to refactor lots of code
within the framework my development team is consuming.  I don't, for
various reasons (not wanting to fork/diverge too much from Qt mainline,
pain of maintaining our own one-offs across taking new drops of Qt, etc).

So far you've been more focused on smacking down my proposal and
(demonstrating your superior knowledge of compiler design) than in finding
workable modifications or alternatives to my proposal.  Since nobody likes
a Debbie Downer, can you please offer something constructive by using your
expertise to suggest a realistically workable alternative to the problem at
hand giiven my team's constraints (which are, by the way, very common in
commercial software development)?

--

---
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/.

------=_Part_3934_687832138.1444852461461
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, October 14, 2015 at 10:51:02 AM UTC-7, Nicol Bolas wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Tuesday, Octob=
er 13, 2015 at 3:58:48 PM UTC-4, <a>keith....@gmail.com</a> wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">To clarify, I&#39;m not sug=
gesting the compiler prove that every return path *results* in foo::bar() h=
aving been called indirectly by way of some other function call. =C2=A0I&#3=
9;m suggesting the compiler prove that a literal direct call to foo::bar() =
appears in execution flow before every possible return path from the functi=
on.</div></blockquote><div><br>OK, now that we&#39;ve cleared up the questi=
on of whether `return` has the behavior you want, we can ask an important q=
uestion:<br><br>Would it be a good idea to give this `extendable` the behav=
ior you desire?<br><br>My answer: no, it would not.<br></div></div></blockq=
uote><div><br></div><div>All of your arguments assume I have the power to r=
efactor lots of code within the framework my development team is consuming.=
 =C2=A0I don&#39;t, for various reasons (not wanting to fork/diverge too mu=
ch from Qt mainline, pain of maintaining our own one-offs across taking new=
 drops of Qt, etc).</div><div><br></div><div>So far you&#39;ve been more fo=
cused on smacking down my proposal and (demonstrating your superior knowled=
ge of compiler design) than in finding workable modifications or alternativ=
es to my proposal. =C2=A0Since nobody likes a Debbie Downer, can you please=
 offer something constructive by using your expertise to suggest a realisti=
cally workable alternative to the problem at hand giiven my team&#39;s cons=
traints (which are, by the way, very common in commercial software developm=
ent)?</div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_3934_687832138.1444852461461--
------=_Part_3933_2068134983.1444852461461--

.

On 2015-10-14 15:50, Miro Knejp wrote:
> Am 14.10.2015 um 18:55 schrieb Matthew Woehlke:
>> On 2015-10-14 12:36, Miro Knejp wrote:
>>> That's all besides the point. The CFG is constructed for all possible
>>> static paths through the function.
>>
>> No, it isn't. My general impression is that folks object to making a
>> function ill-formed due to a code path that *cannot actually ever
>> execute*. And in particular, *I* object to that, which is the point I am
>> trying to make that you seem happy to ignore.
>
> Sorry, but whether the proposed feature categorizes functions as
> ill-formed or not has nothing to do with whether the compiler is capable
> of constructing a CFG for all possible paths through a function and
> analyze their properties as evidenced by actual compiler output.

I agree (if you replace "possible" with "conceivable" in the above).
However, once again, you completely miss the point.

Rather, that's *exactly* the point... what the compiler can do with a
CFG is irrelevant to whether or not the compiler should determine that a
function is ill-formed, either due to this proposal, or in order to
avoid the UB of a function that does not return properly.

CFG analysis is not adequate for that purpose. *That* is the point.

Oh, and...

> You claimed it is a hard problem, I showed otherwise.

....I call straw man. You are constructing a problem that is not the
point I was trying to make and trying to claim that my position is wrong
by proving something that I didn't claim is false.

> I am merely telling you, from a purely technical standpoint, that the
> feature as worded by the OP is easily implementable, which was put
> into question. Period. That's all I said.

You are working from a different definition of "possible". You are
taking "possible" to mean "conceivable". I am taking "possible" in the
literal sense.

As in:

  int foo()
  {
    if (bar) return 0;
  }

  // separate TU
  bool bar() { return true; }

It *is not* possible in the above (barring hardware failure) for foo to
fail to return properly. It's also not possible for the compiler to
correctly make that determination. CFG is not adequate, as it can only
assume that all outcomes of any branch are possible, which may not
actually be the case. (Maybe the compiler can whittle some down, but
there will always exist some program for which some outcome is in fact
impossible, but for which the compiler - even with LTO - cannot prove
that to be the case; if it could, it could solve the halting problem.)

Anyway, see also Nicol's reply, which (also) understands why relying on
CFG to determine reachability for the sake of defining ill-formedness is
a bad idea.

> [*] interestingly -fstrict-enums doesn't seem to have an effect in this
> case under -O0 and -O1

Indeed, I noticed that also... (It doesn't suppress a warning under -O3
even. That seems like a bug. And also goes back to my point that the
compiler can't determine *possible* paths, only *conceivable* paths, and
that therefore it would be nice if we had a way to help the compiler out
in that respect.)

--
Matthew

--

---
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 2015-10-14 15:54, keith.f.kelly@gmail.com wrote:
> All of your arguments assume I have the power to refactor lots of code
> within the framework my development team is consuming.  I don't, for
> various reasons (not wanting to fork/diverge too much from Qt mainline,
> pain of maintaining our own one-offs across taking new drops of Qt, etc).

How does your proposal *not* require making changes to your framework
library? (I assume you mean Qt, but we'll keep things generic...) You'd
still have to change all of the base virtuals to "extendable". (Were you
planning to '#define virtual extendable' or something?)

Thiago has already stated that Qt will not use this feature even if it
were to be approved, so no matter what, you're stuck either using a
locally modified copy anyway, or coming up with a feature that is used
only at the point where a virtual is overridden.

> So far you've been more focused on smacking down my proposal and
> (demonstrating your superior knowledge of compiler design) than in finding
> workable modifications or alternatives to my proposal.

Many people feel that, when something is a terrible idea, it's better to
kill it quick and kill it dead than waste time on it. This forum exists
for the benefit of the community, not you personally. If you had an idea
for, say, a new kitchen appliance, you wouldn't expect to take it to a
manufacturer and have them work out all the bugs in it without being
paid in some form, would you?

In general, in the standard process, unless something is simply so
genuinely brilliant that its advantage is blindingly obvious, it's up to
the proposer (i.e. you) to show why a proposal is worthwhile.

And besides...

> Since nobody likes a Debbie Downer, can you please offer something
> constructive by using your expertise to suggest a realistically
> workable alternative to the problem at hand giiven my team's
> constraints (which are, by the way, very common in commercial
> software development)?

....I already *did* suggest: have an attribute that *warns* if the base
method doesn't get called (and another to suppress the warning when you
really mean to not call it). On the base class, this could be something
like:

  virtual int foo() [[extend_only]];

Or, you could write on a derived class:

  virtual int foo() [[extends]];

The "extends" attribute would imply "override", so you could replace
'override' with '[[extends]]', and existing tools (e.g. clang-modernize)
would be able to help you find places you forgot the attribute.

You can, of course, choose to promote the warning to an error in your
project. If that policy works for you, go for it. Having it be a warning
removes the problem that you are trying to break everyone else's
perfectly valid code.

I suggested adding this support to an existing compiler as an extension
and trying to get it upstreamed.

--
Matthew

--

---
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 14 October 2015 at 23:45, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> ...I already *did* suggest: have an attribute that *warns* if the base
> method doesn't get called (and another to suppress the warning when you
> really mean to not call it). On the base class, this could be something
> like:
>   virtual int foo() [[extend_only]];

virtual int foo() requires_base_call;
or
virtual int foo() [[requires_base_call]];

> Or, you could write on a derived class:
>   virtual int foo() [[extends]];

virtual int foo() calls_base;
or
virtual int foo() [[calls_base]];

> The "extends" attribute would imply "override", so you could replace

No, don't do that, an attribute should not have such a semantic effect.

Anyway, what I outline above is a contract. The base function says that
it must be called, and the derived function promises to do so. No
call graph analysis, no need to look at the body at all, fully declarative.
Not foolproof, certainly, but close to trivial to implement.

--

---
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 Wednesday 14 October 2015 12:54:21 keith.f.kelly@gmail.com wrote:
> I don't, for
> various reasons (not wanting to fork/diverge too much from Qt mainline,
> pain of maintaining our own one-offs across taking new drops of Qt, etc).

I already said Qt will not use this attribute/keyword, even if it were added
and even if we did not have backwards compatibility to retain.
--
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

--

---
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/.

.

------=_Part_33_969175712.1444859963644
Content-Type: multipart/alternative;
 boundary="----=_Part_34_1866110417.1444859963645"

------=_Part_34_1866110417.1444859963645
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 14, 2015 at 3:54:21 PM UTC-4, keith....@gmail.com
wrote:
>
> On Wednesday, October 14, 2015 at 10:51:02 AM UTC-7, Nicol Bolas wrote:
>>
>> On Tuesday, October 13, 2015 at 3:58:48 PM UTC-4, keith....@gmail.com
>> wrote:
>>>
>>> To clarify, I'm not suggesting the compiler prove that every return path
>>> *results* in foo::bar() having been called indirectly by way of some other
>>> function call.  I'm suggesting the compiler prove that a literal direct
>>> call to foo::bar() appears in execution flow before every possible return
>>> path from the function.
>>>
>>
>> OK, now that we've cleared up the question of whether `return` has the
>> behavior you want, we can ask an important question:
>>
>> Would it be a good idea to give this `extendable` the behavior you desire?
>>
>> My answer: no, it would not.
>>
>
> All of your arguments assume I have the power to refactor lots of code
> within the framework my development team is consuming. I don't, for various
> reasons (not wanting to fork/diverge too much from Qt mainline, pain of
> maintaining our own one-offs across taking new drops of Qt, etc).
>

Well... yes, that would be the assumption. You asked for a keyword to
modify the original source code. Therefore, being able to modify the
original source code would be a logical assumption for users of it.

Also, I have to say, it's rather selfish to ask for a feature that's so
specific to *your* particular needs. You're basically saying, "yes, it
would be nice if I could modify the classes I'm deriving from, but I can't,
so just give me a language feature to fix it."

Language features ought to be more generally useful than that.


> So far you've been more focused on smacking down my proposal and
> (demonstrating your superior knowledge of compiler design) than in finding
> workable modifications or alternatives to my proposal.  Since nobody likes
> a Debbie Downer, can you please offer something constructive by using your
> expertise to suggest a realistically workable alternative to the problem at
> hand giiven my team's constraints (which are, by the way, very common in
> commercial software development)?
>

Constructiveness is in the eye of the beholder.

I believe your proposal is a bad idea. I believe it would lead to badly
written code. I believe that there are more effective ways to achieve what
you want with existing language features (whether you personally happen to
be in a position to employ them or not, they still exist). Even looked at
purely as a solution to the problem, I find that it causes undue burden on
the programmer implementing it, forcing them to structure their code around
an arbitrary restriction.

The most constructive thing I can do *for the language* is to explain how
your proposal is a bad idea and provide evidence for that position. That
may not help you or your team, but C++ is bigger than you and your team.
This is *standard* proposals, after all. So that's where I focus my
constructive efforts: on trying to help the language get better.

And I believe your feature would make the language worse.

As an attribute? Sure, knock yourself out (as long as there's a way to tag
a function to opt out). An actual core language feature? No.

--

---
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/.

------=_Part_34_1866110417.1444859963645
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, October 14, 2015 at 3:54:21 PM UTC-4, keith....@gmail.com wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Wednesday, October 14, 2=
015 at 10:51:02 AM UTC-7, Nicol Bolas wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">On Tuesday, October 13, 2015 at 3:58:48 PM UTC-4,=
 <a>keith....@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">To clarify, I&#39;m not suggesting the compiler prove tha=
t every return path *results* in foo::bar() having been called indirectly b=
y way of some other function call. =C2=A0I&#39;m suggesting the compiler pr=
ove that a literal direct call to foo::bar() appears in execution flow befo=
re every possible return path from the function.</div></blockquote><div><br=
>OK, now that we&#39;ve cleared up the question of whether `return` has the=
 behavior you want, we can ask an important question:<br><br>Would it be a =
good idea to give this `extendable` the behavior you desire?<br><br>My answ=
er: no, it would not.<br></div></div></blockquote><div><br></div><div>All o=
f your arguments assume I have the power to refactor lots of code within th=
e framework my development team is consuming. I don&#39;t, for various reas=
ons (not wanting to fork/diverge too=20
much from Qt mainline, pain of maintaining our own one-offs across=20
taking new drops of Qt, etc).</div></blockquote><div><br>Well... yes, that =
would be the assumption. You asked for a keyword to modify the original sou=
rce code. Therefore, being able to modify the original source code would be=
 a logical assumption for users of it.<br><br>Also, I have to say, it&#39;s=
 rather selfish to ask for a feature that&#39;s so specific to <i>your</i> =
particular needs. You&#39;re basically saying, &quot;yes, it would be nice =
if I could modify the classes I&#39;m deriving from, but I can&#39;t, so ju=
st give me a language feature to fix it.&quot;<br><br>Language features oug=
ht to be more generally useful than that.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>So far you&#39;ve been more focused on sma=
cking down my proposal and (demonstrating your superior knowledge of compil=
er design) than in finding workable modifications or alternatives to my pro=
posal. =C2=A0Since nobody likes a Debbie Downer, can you please offer somet=
hing constructive by using your expertise to suggest a realistically workab=
le alternative to the problem at hand giiven my team&#39;s constraints (whi=
ch are, by the way, very common in commercial software development)?</div><=
/blockquote><div><br>Constructiveness is in the eye of the beholder.<br><br=
>I believe your proposal is a bad idea. I believe it would lead to badly wr=
itten code. I believe that there are more effective ways to achieve what yo=
u want with existing language features (whether you personally happen to be=
 in a position to employ them or not, they still exist). Even looked at pur=
ely as a solution to the problem, I find that it causes undue burden on the=
 programmer implementing it, forcing them to structure their code around an=
 arbitrary restriction.<br><br>The most constructive thing I can do <i>for =
the language</i> is to explain how your proposal is a bad idea and provide =
evidence for that position. That may not help you or your team, but C++ is =
bigger than you and your team. This is <i>standard</i> proposals, after all=
.. So that&#39;s where I focus my constructive efforts: on trying to help th=
e language get better.<br><br>And I believe your feature would make the lan=
guage worse.<br><br>As an attribute? Sure, knock yourself out (as long as t=
here&#39;s a way to tag a function to opt out). An actual core language fea=
ture? No.<br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_34_1866110417.1444859963645--
------=_Part_33_969175712.1444859963644--

.

Am 14.10.2015 um 22:27 schrieb Matthew Woehlke:
> On 2015-10-14 15:50, Miro Knejp wrote:
>> Am 14.10.2015 um 18:55 schrieb Matthew Woehlke:
>>> On 2015-10-14 12:36, Miro Knejp wrote:
>>>> That's all besides the point. The CFG is constructed for all possible
>>>> static paths through the function.
>>> No, it isn't. My general impression is that folks object to making a
>>> function ill-formed due to a code path that *cannot actually ever
>>> execute*. And in particular, *I* object to that, which is the point I am
>>> trying to make that you seem happy to ignore.
>> Sorry, but whether the proposed feature categorizes functions as
>> ill-formed or not has nothing to do with whether the compiler is capable
>> of constructing a CFG for all possible paths through a function and
>> analyze their properties as evidenced by actual compiler output.
> I agree (if you replace "possible" with "conceivable" in the above).
> However, once again, you completely miss the point.
 From the information available to the compiler when examining the
function's body in isolation it makes no difference. It has to assume
that all well-defined control flow paths are active at runtime. We are
not in disagreement here nor do I miss the point. I know exactly what
you're talking about, I know exactly why the CFG analysis is not bullet
proof, but that was never *my* point. See below.
>
> Rather, that's *exactly* the point... what the compiler can do with a
> CFG is irrelevant to whether or not the compiler should determine that a
> function is ill-formed, either due to this proposal, or in order to
> avoid the UB of a function that does not return properly.
>
> CFG analysis is not adequate for that purpose. *That* is the point.
Which I never claimed. The OP presented his vision of the feature, was
told that it was technically hard or impossible to implement and I
showed that the technical argument against*his* specific version of the
feature is unfounded. Plenty of people brought up other forms of
opposition to the table (including why the strict control flow approach
is inferior) which I have abstained from participating in because I was
only about clearing up a technical question.
>
> Oh, and...
>
>> You claimed it is a hard problem, I showed otherwise.
> ...I call straw man. You are constructing a problem that is not the
> point I was trying to make and trying to claim that my position is wrong
> by proving something that I didn't claim is false.
Funny how one is supposedly able to use a straw man when not even
arguing for any side :-)
>
>> I am merely telling you, from a purely technical standpoint, that the
>> feature as worded by the OP is easily implementable, which was put
>> into question. Period. That's all I said.
> You are working from a different definition of "possible". You are
> taking "possible" to mean "conceivable". I am taking "possible" in the
> literal sense.
I use the the definitions of "possible" and "conceivable" as per the
English language, where they mean the same. Since this is an
international forum with many non-native speakers it'd be great if we
didn't invent new definitions for existing words, thank you :-)
http://www.oxforddictionaries.com/definition/english-thesaurus/possible
>
> As in:
>
>    int foo()
>    {
>      if (bar) return 0;
>    }
>
>    // separate TU
>    bool bar() { return true; }
>
> It *is not* possible in the above (barring hardware failure) for foo to
> fail to return properly. It's also not possible for the compiler to
> correctly make that determination. CFG is not adequate, as it can only
> assume that all outcomes of any branch are possible, which may not
> actually be the case. (Maybe the compiler can whittle some down, but
> there will always exist some program for which some outcome is in fact
> impossible, but for which the compiler - even with LTO - cannot prove
> that to be the case; if it could, it could solve the halting problem.)
I have never claimed otherwise? You realize I was talking about isolated
*static* control flow analysis, right? In foo the compiler has to assume
the else branch is reachable and it will emit a diagnostic about a
missing return. How it deals with the lacking return is nobody's
business. The difference between this example and the one with the
enum/switch is that in this case the block lacking a return can be
reached without the presence of UB. The enum/switch example can only
reach the block without return via UB:

int foo() {
   if(fun1()) return 1;
   if(fun2()) return 2;
   // Can be rached in a well-defined program
   fun3();
   // UB is only the lack of return if this is reached.
   // Warns about missing return
}

enum class E {A, B};
int foo2(E e) {
   switch(e) {
     case E::A: return 1;
     case E::B: return 2;
   }
   // Cannot be reached in a well-defined program
   // Compiler is free to remove this node from the CFG
   // Does not warn about missing return
}
This is an important distinction.
>
> Anyway, see also Nicol's reply, which (also) understands why relying on
> CFG to determine reachability for the sake of defining ill-formedness is
> a bad idea.
>
>> [*] interestingly -fstrict-enums doesn't seem to have an effect in this
>> case under -O0 and -O1
> Indeed, I noticed that also... (It doesn't suppress a warning under -O3
> even. That seems like a bug. And also goes back to my point that the
> compiler can't determine *possible* paths, only *conceivable* paths, and
> that therefore it would be nice if we had a way to help the compiler out
> in that respect.)
>

--

---
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/.

.

------=_Part_70_1899451134.1444866988183
Content-Type: multipart/alternative;
 boundary="----=_Part_71_180670616.1444866988183"

------=_Part_71_180670616.1444866988183
Content-Type: text/plain; charset=UTF-8

On Wednesday, October 14, 2015 at 6:29:14 PM UTC-4, Miro Knejp wrote:
>
> Am 14.10.2015 um 22:27 schrieb Matthew Woehlke:
> <http://www.oxforddictionaries.com/definition/english-thesaurus/possible>
> >
> > As in:
> >
> >    int foo()
> >    {
> >      if (bar) return 0;
> >    }
> >
> >    // separate TU
> >    bool bar() { return true; }
> >
> > It *is not* possible in the above (barring hardware failure) for foo to
> > fail to return properly. It's also not possible for the compiler to
> > correctly make that determination. CFG is not adequate, as it can only
> > assume that all outcomes of any branch are possible, which may not
> > actually be the case. (Maybe the compiler can whittle some down, but
> > there will always exist some program for which some outcome is in fact
> > impossible, but for which the compiler - even with LTO - cannot prove
> > that to be the case; if it could, it could solve the halting problem.)
> I have never claimed otherwise? You realize I was talking about isolated
> *static* control flow analysis, right? In foo the compiler has to assume
> the else branch is reachable and it will emit a diagnostic about a
> missing return. How it deals with the lacking return is nobody's
> business. The difference between this example and the one with the
> enum/switch is that in this case the block lacking a return can be
> reached without the presence of UB. The enum/switch example can only
> reach the block without return via UB:
>
> int foo() {
>    if(fun1()) return 1;
>    if(fun2()) return 2;
>    // Can be rached in a well-defined program
>    fun3();
>    // UB is only the lack of return if this is reached.
>    // Warns about missing return
> }
>
> enum class E {A, B};
> int foo2(E e) {
>    switch(e) {
>      case E::A: return 1;
>      case E::B: return 2;
>    }
>    // Cannot be reached in a well-defined program
>    // Compiler is free to remove this node from the CFG
>    // Does not warn about missing return
> }
> This is an important distinction.
>

As we have been reminded recently
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/XlT6rFrCL4M>,
there is nothing undefined in C++ about this statement:

E e = static_cast<E>(5);

Even though `E` is an `enum class`, this remains valid, well-defined code
according to C++(11&14). As an enum class, `E`'s default underlying type is
`int`. That is large enough to hold the integer value 5. Therefore, it is
perfectly acceptable to perform this conversion.

And therefore, it is perfectly valid (doubious, but valid) and well-defined
as to what happens if you pass the value of `e` to `foo2`. Nothing of this
is undefined behavior. Therefore, it does not *require* UB to reach the bad
part of `foo2`.

--

---
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/.

------=_Part_71_180670616.1444866988183
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, October 14, 2015 at 6:29:14 PM UTC-4, Miro Knejp wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">Am 14.10.2015 um 22:27 schrieb Matth=
ew Woehlke:
<br><a href=3D"http://www.oxforddictionaries.com/definition/english-thesaur=
us/possible" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.oxforddictionaries.com%=
2Fdefinition%2Fenglish-thesaurus%2Fpossible\46sa\75D\46sntz\0751\46usg\75AF=
QjCNG_i0_FLyHySN2Fd-cX-Z0gDqDWTQ&#39;;return true;" onclick=3D"this.href=3D=
&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.oxforddictionaries.com%=
2Fdefinition%2Fenglish-thesaurus%2Fpossible\46sa\75D\46sntz\0751\46usg\75AF=
QjCNG_i0_FLyHySN2Fd-cX-Z0gDqDWTQ&#39;;return true;"></a> <br>&gt;
<br>&gt; As in:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0int foo()
<br>&gt; =C2=A0 =C2=A0{
<br>&gt; =C2=A0 =C2=A0 =C2=A0if (bar) return 0;
<br>&gt; =C2=A0 =C2=A0}
<br>&gt;
<br>&gt; =C2=A0 =C2=A0// separate TU
<br>&gt; =C2=A0 =C2=A0bool bar() { return true; }
<br>&gt;
<br>&gt; It *is not* possible in the above (barring hardware failure) for f=
oo to
<br>&gt; fail to return properly. It&#39;s also not possible for the compil=
er to
<br>&gt; correctly make that determination. CFG is not adequate, as it can =
only
<br>&gt; assume that all outcomes of any branch are possible, which may not
<br>&gt; actually be the case. (Maybe the compiler can whittle some down, b=
ut
<br>&gt; there will always exist some program for which some outcome is in =
fact
<br>&gt; impossible, but for which the compiler - even with LTO - cannot pr=
ove
<br>&gt; that to be the case; if it could, it could solve the halting probl=
em.)
<br>I have never claimed otherwise? You realize I was talking about isolate=
d=20
<br>*static* control flow analysis, right? In foo the compiler has to assum=
e=20
<br>the else branch is reachable and it will emit a diagnostic about a=20
<br>missing return. How it deals with the lacking return is nobody&#39;s=20
<br>business. The difference between this example and the one with the=20
<br>enum/switch is that in this case the block lacking a return can be=20
<br>reached without the presence of UB. The enum/switch example can only=20
<br>reach the block without return via UB:
<br>
<br>int foo() {
<br>=C2=A0 =C2=A0if(fun1()) return 1;
<br>=C2=A0 =C2=A0if(fun2()) return 2;
<br>=C2=A0 =C2=A0// Can be rached in a well-defined program
<br>=C2=A0 =C2=A0fun3();
<br>=C2=A0 =C2=A0// UB is only the lack of return if this is reached.
<br>=C2=A0 =C2=A0// Warns about missing return
<br>}
<br>
<br>enum class E {A, B};
<br>int foo2(E e) {
<br>=C2=A0 =C2=A0switch(e) {
<br>=C2=A0 =C2=A0 =C2=A0case E::A: return 1;
<br>=C2=A0 =C2=A0 =C2=A0case E::B: return 2;
<br>=C2=A0 =C2=A0}
<br>=C2=A0 =C2=A0// Cannot be reached in a well-defined program
<br>=C2=A0 =C2=A0// Compiler is free to remove this node from the CFG
<br>=C2=A0 =C2=A0// Does not warn about missing return
<br>}
<br>This is an important distinction.
<br></blockquote><div><br><a href=3D"https://groups.google.com/a/isocpp.org=
/forum/#!topic/std-proposals/XlT6rFrCL4M">As we have been reminded recently=
</a>, there is nothing undefined in C++ about this statement:<br><br>E e =
=3D static_cast&lt;E&gt;(5);<br><br>Even though `E` is an `enum class`, thi=
s remains valid, well-defined code according to C++(11&amp;14). As an enum =
class, `E`&#39;s default underlying type is `int`. That is large enough to =
hold the integer value 5. Therefore, it is perfectly acceptable to perform =
this conversion.<br><br>And therefore, it is perfectly valid (doubious, but=
 valid) and well-defined as to what happens if you pass the value of `e` to=
 `foo2`. Nothing of this is undefined behavior. Therefore, it does not <i>r=
equire</i> UB to reach the bad part of `foo2`.<br></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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_71_180670616.1444866988183--
------=_Part_70_1899451134.1444866988183--

.

This is a multi-part message in MIME format.
--------------030908060307060207090402
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 15.10.2015 um 01:56 schrieb Nicol Bolas:
> On Wednesday, October 14, 2015 at 6:29:14 PM UTC-4, Miro Knejp wrote:
>
>     Am 14.10.2015 um 22:27 schrieb Matthew Woehlke:
>
>     >
>     > As in:
>     >
>     >    int foo()
>     >    {
>     >      if (bar) return 0;
>     >    }
>     >
>     >    // separate TU
>     >    bool bar() { return true; }
>     >
>     > It *is not* possible in the above (barring hardware failure) for
>     foo to
>     > fail to return properly. It's also not possible for the compiler to
>     > correctly make that determination. CFG is not adequate, as it
>     can only
>     > assume that all outcomes of any branch are possible, which may not
>     > actually be the case. (Maybe the compiler can whittle some down,
>     but
>     > there will always exist some program for which some outcome is
>     in fact
>     > impossible, but for which the compiler - even with LTO - cannot
>     prove
>     > that to be the case; if it could, it could solve the halting
>     problem.)
>     I have never claimed otherwise? You realize I was talking about
>     isolated
>     *static* control flow analysis, right? In foo the compiler has to
>     assume
>     the else branch is reachable and it will emit a diagnostic about a
>     missing return. How it deals with the lacking return is nobody's
>     business. The difference between this example and the one with the
>     enum/switch is that in this case the block lacking a return can be
>     reached without the presence of UB. The enum/switch example can only
>     reach the block without return via UB:
>
>     int foo() {
>        if(fun1()) return 1;
>        if(fun2()) return 2;
>        // Can be rached in a well-defined program
>        fun3();
>        // UB is only the lack of return if this is reached.
>        // Warns about missing return
>     }
>
>     enum class E {A, B};
>     int foo2(E e) {
>        switch(e) {
>          case E::A: return 1;
>          case E::B: return 2;
>        }
>        // Cannot be reached in a well-defined program
>        // Compiler is free to remove this node from the CFG
>        // Does not warn about missing return
>     }
>     This is an important distinction.
>
>
> As we have been reminded recently
> <https://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposals/XlT6rFrCL4M>,
> there is nothing undefined in C++ about this statement:
>
> E e = static_cast<E>(5);
>
> Even though `E` is an `enum class`, this remains valid, well-defined
> code according to C++(11&14). As an enum class, `E`'s default
> underlying type is `int`. That is large enough to hold the integer
> value 5. Therefore, it is perfectly acceptable to perform this conversion.
>
> And therefore, it is perfectly valid (doubious, but valid) and
> well-defined as to what happens if you pass the value of `e` to
> `foo2`. Nothing of this is undefined behavior. Therefore, it does not
> /require/ UB to reach the bad part of `foo2`.
True, I accidentally used enum class, meant to use enum, in which case
see Richard's statement from earlier (it now also explains why I didn't
see any difference with -fstrict-enums). Sigh, more straw men,
wonderful, as if we didn't have enough already. BTW, did you notice
Matthew wrote if(bar) instead of if(bar())? You should pick on that as
well, just for completeness sake. That'd make me feel so much better.
Anyway that's not the point and I'm sure you were very well aware of
that. The important part is the condition of entering a block never
possibly being true if the program is well defined, giving the compiler
the freedom to ignore that transition entirely, therefore making it
irrelevant to raise any diagnostics for operations that are post
dominated solely by the offending node, including not warning about a
missing return.

--

---
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/.

--------------030908060307060207090402
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    Am 15.10.2015 um 01:56 schrieb Nicol Bolas:<br>
    <blockquote
      cite=3D"mid:83a6ba7b-5599-4886-a6c3-8338fc714553@isocpp.org"
      type=3D"cite">On Wednesday, October 14, 2015 at 6:29:14 PM UTC-4,
      Miro Knejp wrote:
      <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
        0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Am
        14.10.2015 um 22:27 schrieb Matthew Woehlke:
        <br>
        <br>
        &gt;
        <br>
        &gt; As in:
        <br>
        &gt;
        <br>
        &gt; =C2=A0 =C2=A0int foo()
        <br>
        &gt; =C2=A0 =C2=A0{
        <br>
        &gt; =C2=A0 =C2=A0 =C2=A0if (bar) return 0;
        <br>
        &gt; =C2=A0 =C2=A0}
        <br>
        &gt;
        <br>
        &gt; =C2=A0 =C2=A0// separate TU
        <br>
        &gt; =C2=A0 =C2=A0bool bar() { return true; }
        <br>
        &gt;
        <br>
        &gt; It *is not* possible in the above (barring hardware
        failure) for foo to
        <br>
        &gt; fail to return properly. It's also not possible for the
        compiler to
        <br>
        &gt; correctly make that determination. CFG is not adequate, as
        it can only
        <br>
        &gt; assume that all outcomes of any branch are possible, which
        may not
        <br>
        &gt; actually be the case. (Maybe the compiler can whittle some
        down, but
        <br>
        &gt; there will always exist some program for which some outcome
        is in fact
        <br>
        &gt; impossible, but for which the compiler - even with LTO -
        cannot prove
        <br>
        &gt; that to be the case; if it could, it could solve the
        halting problem.)
        <br>
        I have never claimed otherwise? You realize I was talking about
        isolated <br>
        *static* control flow analysis, right? In foo the compiler has
        to assume <br>
        the else branch is reachable and it will emit a diagnostic about
        a <br>
        missing return. How it deals with the lacking return is nobody's
        <br>
        business. The difference between this example and the one with
        the <br>
        enum/switch is that in this case the block lacking a return can
        be <br>
        reached without the presence of UB. The enum/switch example can
        only <br>
        reach the block without return via UB:
        <br>
        <br>
        int foo() {
        <br>
        =C2=A0 =C2=A0if(fun1()) return 1;
        <br>
        =C2=A0 =C2=A0if(fun2()) return 2;
        <br>
        =C2=A0 =C2=A0// Can be rached in a well-defined program
        <br>
        =C2=A0 =C2=A0fun3();
        <br>
        =C2=A0 =C2=A0// UB is only the lack of return if this is reached.
        <br>
        =C2=A0 =C2=A0// Warns about missing return
        <br>
        }
        <br>
        <br>
        enum class E {A, B};
        <br>
        int foo2(E e) {
        <br>
        =C2=A0 =C2=A0switch(e) {
        <br>
        =C2=A0 =C2=A0 =C2=A0case E::A: return 1;
        <br>
        =C2=A0 =C2=A0 =C2=A0case E::B: return 2;
        <br>
        =C2=A0 =C2=A0}
        <br>
        =C2=A0 =C2=A0// Cannot be reached in a well-defined program
        <br>
        =C2=A0 =C2=A0// Compiler is free to remove this node from the CFG
        <br>
        =C2=A0 =C2=A0// Does not warn about missing return
        <br>
        }
        <br>
        This is an important distinction.
        <br>
      </blockquote>
      <div><br>
        <a moz-do-not-send=3D"true"
href=3D"https://groups.google.com/a/isocpp.org/forum/#%21topic/std-proposal=
s/XlT6rFrCL4M">As
          we have been reminded recently</a>, there is nothing undefined
        in C++ about this statement:<br>
        <br>
        E e =3D static_cast&lt;E&gt;(5);<br>
        <br>
        Even though `E` is an `enum class`, this remains valid,
        well-defined code according to C++(11&amp;14). As an enum class,
        `E`'s default underlying type is `int`. That is large enough to
        hold the integer value 5. Therefore, it is perfectly acceptable
        to perform this conversion.<br>
        <br>
        And therefore, it is perfectly valid (doubious, but valid) and
        well-defined as to what happens if you pass the value of `e` to
        `foo2`. Nothing of this is undefined behavior. Therefore, it
        does not <i>require</i> UB to reach the bad part of `foo2`.<br>
      </div>
    </blockquote>
    True, I accidentally used enum class, meant to use enum, in which
    case see Richard's statement from earlier (it now also explains why
    I didn't see any difference with -fstrict-enums). Sigh, more straw
    men, wonderful, as if we didn't have enough already. BTW, did you
    notice Matthew wrote if(bar) instead of if(bar())? You should pick
    on that as well, just for completeness sake. That'd make me feel so
    much better. Anyway that's not the point and I'm sure you were very
    well aware of that. The important part is the condition of entering
    a block never possibly being true if the program is well defined,
    giving the compiler the freedom to ignore that transition entirely,
    therefore making it irrelevant to raise any diagnostics for
    operations that are post dominated solely by the offending node,
    including not warning about a missing return.<br>
  </body>
</html>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--------------030908060307060207090402--

.

On 2015-10-14 17:11, Ville Voutilainen wrote:
> On 14 October 2015 at 23:45, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> ...I already *did* suggest: have an attribute that *warns* if the base
>> method doesn't get called (and another to suppress the warning when you
>> really mean to not call it). On the base class, this could be something
>> like:
>>   virtual int foo() [[extend_only]];
>
> virtual int foo() requires_base_call;
> or
> virtual int foo() [[requires_base_call]];

Somehow I suspect compilers are going to look less favorably on a
contextual keyword as an extension than on an attribute. (Pedantic: it
wouldn't anyway be [[extend_only]] most likely, but rather like
[[gnu::extend_only]] or [[clang::extend_only]] or such.)

>> Or, you could write on a derived class:
>>   virtual int foo() [[extends]];
>
> virtual int foo() calls_base;
> or
> virtual int foo() [[calls_base]];
>
>> The "extends" attribute would imply "override", so you could replace
>
> No, don't do that, an attribute should not have such a semantic effect.

Obviously as a standard proposal it probably won't do that. As a vendor
attribute, I don't see the problem at least *warning* if a
[[vendor::calls_base]] does not override, as a convenience to avoid
having to write both the attribute *and* 'override'.

> Anyway, what I outline above is a contract. The base function says that
> it must be called, and the derived function promises to do so. No
> call graph analysis, no need to look at the body at all, fully declarative.
> Not foolproof, certainly, but close to trivial to implement.

Um... doesn't that defeat the whole purpose? The point of the OP's
request was to diagnose *violations* of the contract. That means the
body of the method *must* be inspected. Otherwise you're just throwing
around meaningless annotations.

Note that the point of my suggestion was that only *one* of the
attributes is needed. The attribute on the base member implies that all
overrides should call the base member, and to warn if they don't. The
attribute on the overriding member is when the programmer knows that the
override should call the base, to tell the compiler to warn if it
doesn't. The latter is intended for cases where the attribute can't be
used on the former (e.g. because the base member is in an external
library that cannot be modified).

--
Matthew

--

---
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/.

.

--001a11459a40eed0f305222602c4
Content-Type: text/plain; charset=UTF-8

On 15 October 2015 at 09:34, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> The attribute on the base member implies that all
> overrides should call the base member, and to warn if they don't.


Does it?

Take the following case:

class A {

    virtual void f() [[extendable]] { /* ... */ }

};


class B : public A {

    void f() override { /* ... */ A::f(); /* ... */ }

};


class C : public B {

    void f() override { /* Should it call A::f()?  B::f()?  or neither? */ }

};


class D : public A {

    void f() override [[extendable]] { /* ... */ A::f(); /* ... */ }

};


class E : public D {

    void f() override { /* Should it call A::f()?  D::f()?  or neither? */ }

}

One could make a case that C::f() should not necessarily call B::f() and
should not necessarily call A::f().  One could also make the case that
E::f() should call call D::f() and should not necessarily call A::f().
There are, of course, other reasonable possibilities.

Not that I would want such a feature, for all the reasons Nicol and others
have pointed out.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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/.

--001a11459a40eed0f305222602c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 15 October 2015 at 09:34, Matthew Woehlke <span dir=3D"=
ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoe=
hlke.floss@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">The attribute on the base member =
implies that all<br>
overrides should call the base member, and to warn if they don&#39;t. </blo=
ckquote><div><br></div><div>Does it?</div><div><br></div><div>Take the foll=
owing case:</div><div><br></div><div><p style=3D"margin:0px;font-size:11px;=
line-height:normal;font-family:Menlo"><span style=3D"color:rgb(52,189,38)">=
class</span> A {=C2=A0</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>=C2=A0 =C2=A0 <span style=3D"color:rgb(52,189,38)">virtual</span> <span st=
yle=3D"color:rgb(52,189,38)">void</span> f() [[extendable]] { <span style=
=3D"color:rgb(83,48,225)">/* ... */</span> }</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>};</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo;=
min-height:13px"><br></p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
><span style=3D"color:rgb(52,189,38)">class</span> B : <span style=3D"color=
:rgb(206,121,36)">public</span> A {=C2=A0</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>=C2=A0 =C2=A0 <span style=3D"color:rgb(52,189,38)">void</span> f() <span s=
tyle=3D"color:rgb(52,189,38)">override</span> { <span style=3D"color:rgb(83=
,48,225)">/* ... */</span> A::f(); <span style=3D"color:rgb(83,48,225)">/* =
.... */</span> }</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>};</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo;=
min-height:13px"><br></p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
><span style=3D"color:rgb(52,189,38)">class</span> C : <span style=3D"color=
:rgb(206,121,36)">public</span> B {=C2=A0</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(83,48,225)"><span style=3D"color:rgb(0,0,0)">=C2=A0 =C2=A0 </span=
><span style=3D"color:rgb(52,189,38)">void</span><span style=3D"color:rgb(0=
,0,0)"> f() </span><span style=3D"color:rgb(52,189,38)">override</span><spa=
n style=3D"color:rgb(0,0,0)"> { </span>/* Should it call A::f()?=C2=A0 B::f=
()?=C2=A0 or neither? */<span style=3D"color:rgb(0,0,0)"> }</span></p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>};</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo;=
min-height:13px"><br></p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
><span style=3D"color:rgb(52,189,38)">class</span> D : <span style=3D"color=
:rgb(206,121,36)">public</span> A {=C2=A0</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>=C2=A0 =C2=A0 <span style=3D"color:rgb(52,189,38)">void</span> f() <span s=
tyle=3D"color:rgb(52,189,38)">override</span> [[extendable]] { <span style=
=3D"color:rgb(83,48,225)">/* ... */</span> A::f(); <span style=3D"color:rgb=
(83,48,225)">/* ... */</span> }</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>};</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo;=
min-height:13px"><br></p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
><span style=3D"color:rgb(52,189,38)">class</span> E : <span style=3D"color=
:rgb(206,121,36)">public</span> D {=C2=A0</p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(83,48,225)"><span style=3D"color:rgb(0,0,0)">=C2=A0 =C2=A0 </span=
><span style=3D"color:rgb(52,189,38)">void</span><span style=3D"color:rgb(0=
,0,0)"> f() </span><span style=3D"color:rgb(52,189,38)">override</span><spa=
n style=3D"color:rgb(0,0,0)"> { </span>/* Should it call A::f()?=C2=A0 D::f=
()?=C2=A0 or neither? */<span style=3D"color:rgb(0,0,0)"> }</span></p>
<p style=3D"margin:0px;font-size:11px;line-height:normal;font-family:Menlo"=
>}</p></div><div><br></div><div>One could make a case that C::f() should no=
t necessarily call B::f() and should not necessarily call A::f().=C2=A0 One=
 could also make the case that E::f() should call call D::f() and should no=
t necessarily call A::f().=C2=A0 There are, of course, other reasonable pos=
sibilities.</div><div><br></div><div>Not that I would want such a feature, =
for all the reasons Nicol and others have pointed out.</div></div>-- <br><d=
iv>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nev=
in@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0=
 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_bla=
nk">(847) 691-1404</a></div>
</div></div>

<p></p>

-- <br />
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<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 />

--001a11459a40eed0f305222602c4--

.

On 2015-10-15 11:04, Nevin Liber wrote:
> On 15 October 2015 at 09:34, Matthew Woehlke wrote:
>> The attribute on the base member implies that all
>> overrides should call the base member, and to warn if they don't.
>
> Does it?
>
> Take the following case:
>
> class A {
>     virtual void f() [[extendable]] { /* ... */ }
> };
>
> class B : public A {
>     void f() override { /* ... */ A::f(); /* ... */ }
> };
>
> class C : public B {
>     void f() override { /* Should it call A::f()?  B::f()?  or neither? */ }
> };
>
> class D : public A {
>     void f() override [[extendable]] { /* ... */ A::f(); /* ... */ }
> };
>
> class E : public D {
>     void f() override { /* Should it call A::f()?  D::f()?  or neither? */ }
> }

In case of E, definitely D::f(). The direct override case is simple.

In case of C... that's a fair question. Fortunately, I'm not the one
wanting the feature :-).

> Not that I would want such a feature, for all the reasons Nicol and others
> have pointed out.

I can see the usefulness as an *attribute*, that *warns*. I might even
use it, if it existed. I'm not likely to implement it myself, however. I
was just responding to Keith's complaint about the "lack of constructive
feedback" by suggesting a way in which he might continue working on it.

--
Matthew

--

---
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/.

.