------=_Part_6767_1585114784.1447085392641
Content-Type: multipart/alternative;
 boundary="----=_Part_6768_1676496827.1447085392641"

------=_Part_6768_1676496827.1447085392641
Content-Type: text/plain; charset=UTF-8

Consider the following simplified code:

struct Base
{
   virtual void func(int &x);
   virtual void func(double &x);
};

struct Derived : public Base
{
   template<typename T> void func(T &x) final;
};


Because Derived::func() uses the "final" identifier on the method
declaration, the compiler knows that func() is to replace underlying
virtual methods in the inheritance hierarchy. Thus, it should be possible
for the compiler to validate that calls for Derived::func(int &) and
Derived::func(double &) have analogues in Base, declared as virtual
methods. Upon verification, the appropriate method can be generated from
the template for Derived::func(int&) and/or Derived::func(double&),
depending on which method(s) was invoked. Furthermore, the compiler can
generate an error if an attempt is made to use Derived::func() in a call
for which no such signature exists within the underlying base class(es),
like Derived::func(std::string &). The same logic obviously applies for the
use of the identifier "override".

I realize that this is the most simplistic version of this functionality,
and life gets more complicated as you add layers of hierarchy with
templates. However, off the bat, I can't think of a situation that the
compiler can resolve this properly.

I sent this idea to one C++ luminary, and he suggested the following:

struct Derived : public Base
{
   template<typename T> void func(T &x);              // current semantics:
generate non-virtuals
   template<typename T> void func(T &x) final;      // new semantics:
generate virtuals;
};


Am I missing something? It seems like all of the pieces exist for the
compiler to be able to handle this type of extension.

- John Croix


--

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

<div dir=3D"ltr">Consider the following simplified code:<blockquote style=
=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>struct Base</div>=
<div>{</div><div>=C2=A0 =C2=A0virtual void func(int &amp;x);</div><div>=C2=
=A0 =C2=A0virtual void func(double &amp;x);</div><div>};</div><div><br></di=
v><div>struct Derived : public Base</div><div>{</div><div>=C2=A0 =C2=A0temp=
late&lt;typename T&gt; void func(T &amp;x) final;</div><div>};</div></block=
quote><div>=C2=A0<div>Because Derived::func() uses the &quot;final&quot; id=
entifier on the method declaration, the compiler knows that func() is to re=
place underlying virtual methods in the inheritance hierarchy. Thus, it sho=
uld be possible for the compiler to validate that calls for Derived::func(i=
nt &amp;) and Derived::func(double &amp;) have analogues in Base, declared =
as virtual methods. Upon verification, the appropriate method can be genera=
ted from the template for Derived::func(int&amp;) and/or Derived::func(doub=
le&amp;), depending on which method(s) was invoked. Furthermore, the compil=
er can generate an error if an attempt is made to use Derived::func() in a =
call for which no such signature exists within the underlying base class(es=
), like Derived::func(std::string &amp;). The same logic obviously applies =
for the use of the identifier &quot;override&quot;.</div><div><br></div><di=
v>I realize that this is the most simplistic version of this functionality,=
 and life gets more complicated as you add layers of hierarchy with templat=
es. However, off the bat, I can&#39;t think of a situation that the compile=
r can resolve this properly.</div><div><br></div><div>I sent this idea to o=
ne C++ luminary, and he suggested the following:</div></div><blockquote sty=
le=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><div>struc=
t Derived : public Base</div></div></div><div><div><div>{</div></div></div>=
<div><div><div>=C2=A0 =C2=A0template&lt;typename T&gt; void func(T &amp;x);=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// current semantics: gene=
rate non-virtuals</div></div></div><div><div><div>=C2=A0 =C2=A0template&lt;=
typename T&gt; void func(T &amp;x) final; =C2=A0 =C2=A0 =C2=A0// new semant=
ics: generate virtuals;</div></div></div><div><div><div>};</div></div></div=
></blockquote><div><div><br></div><div>Am I missing something? It seems lik=
e all of the pieces exist for the compiler to be able to handle this type o=
f extension.</div><div><br></div><div>- John Croix</div><div><br></div><div=
><br></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_6768_1676496827.1447085392641--
------=_Part_6767_1585114784.1447085392641--

.