Topic: Hide inherited virtual methods (on demand)
Author: toma78b@gmail.com
Date: Mon, 7 May 2018 13:05:48 -0700 (PDT)
Raw View
------=_Part_24293_677229058.1525723548873
Content-Type: multipart/alternative;
boundary="----=_Part_24294_449211666.1525723548873"
------=_Part_24294_449211666.1525723548873
Content-Type: text/plain; charset="UTF-8"
I don't think the example really illustrate why you need such feature. Why
do you need a virtual function if you do not do any polymorphism ?
(Cause you could just remove the virtual keyword or rename the derived
class GetProduct() method, and problem solved.)
On Monday, 7 May 2018 10:59:06 UTC-4, volodym...@globallogic.com wrote:
> Hi.
>
> If method is not virtual, you can simply "hide" it in derived class:
> struct A
> {
> void F() {}
> };
> struct B: public A
> {
> int F() { return 0; }
> };
> But if method is virtual, compiler will try to override it (instead of
> hide). In case of different result types this will leads to errors:
> struct A
> {
> virtual void F() {}
> };
> struct B: public A
> {
> int F() { return 0; } // error, different result types
> };
> In C# such things easily makes via operator "new":
> class A
> {
> public virtual void F() { }
> };
> class B: A
> {
> public new int F() { return 0; }
> }
> I propose to use the similar approach. For example operator "overload":
> struct A
> {
> virtual void F() {}
> };
> struct B: public A
> {
> int F() overload { return 0; } // error, different result types
> };
> This will let us, for example, to use covariance (in general, as approach)
> and smart pointers together:
> // interface
> struct IProduct {};
> struct IPipeline
> {
> virtual std::shared_ptr<IProduct> GetProduct();
> };
>
> // implementation
> struct Product: IProduct {};
> struct Pipeline: IPipeline
> {
> std::shared_ptr<Product> GetProduct() overload;
> };
>
> // usage
> Pipeline pipeline;
> std::shared_ptr<Product> produce = pipeline.GetProduct();
>
> Such approach may be used only in case of "overload" operator usage to
> keep backward compatibility.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/feebae63-0177-48ef-becd-233f13024013%40isocpp.org.
------=_Part_24294_449211666.1525723548873
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I don't think the example really illustrate why y=
ou need such feature. Why do you need a virtual function if you do not do a=
ny polymorphism ?</div><div><br></div><div>(Cause you could just remove the=
virtual keyword or rename the derived class GetProduct() method, and probl=
em solved.)</div><div><br></div><div>On Monday, 7 May 2018 10:59:06 UTC-4, =
volodym...@globallogic.com wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr">Hi.<br><br>If method is not virtual, you can=
simply "hide" it in derived class:<br>struct A<br>{<br>=C2=A0=C2=
=A0=C2=A0 void F() {}<br>};<br>struct B: public A<br>{<br>=C2=A0=C2=A0=C2=
=A0 int F() { return 0; }<br>};<br>But if method is virtual, compiler will =
try to override it (instead of hide). In case of different result types thi=
s will leads to errors:<br>struct A<br>{<br>=C2=A0=C2=A0=C2=A0 virtual void=
F() {}<br>};<br>struct B: public A<br>{<br>=C2=A0=C2=A0=C2=A0 int F() { re=
turn 0; } // error, different result types<br>};<br>In C# such things easil=
y makes via operator "new":<br>class A<br>{<br>=C2=A0=C2=A0=C2=A0=
public virtual void F() { }<br>};<br>class B: A<br>{<br>=C2=A0=C2=A0=C2=A0=
public new int F() { return 0; }<br>}<br>I propose to use the similar appr=
oach. For example operator "overload":<br>struct A<br>{<br>=C2=A0=
=C2=A0=C2=A0 virtual void F() {}<br>};<br>struct B: public A<br>{<br>=C2=A0=
=C2=A0=C2=A0 int F() overload { return 0; } // error, different result type=
s<br>};<br>This will let us, for example, to use covariance (in general, as=
approach) and smart pointers together:<br>// interface<br>struct IProduct =
{};<br>struct IPipeline<br>{<br>=C2=A0=C2=A0=C2=A0 virtual std::shared_ptr&=
lt;IProduct> GetProduct();<br>};<br><br>// implementation<br>struct Prod=
uct: IProduct {};<br>struct Pipeline: IPipeline<br>{<br>=C2=A0=C2=A0=C2=A0 =
std::shared_ptr<Product> GetProduct() overload;<br>};<br><br>// usage=
<br>Pipeline pipeline;<br>std::shared_ptr<Product> produce =3D pipeli=
ne.GetProduct();<br><br>Such approach may be used only in case of "ove=
rload" operator usage to keep backward compatibility.<br></div></block=
quote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/feebae63-0177-48ef-becd-233f13024013%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/feebae63-0177-48ef-becd-233f13024013=
%40isocpp.org</a>.<br />
------=_Part_24294_449211666.1525723548873--
------=_Part_24293_677229058.1525723548873--
.
Author: Jared Grubb <jared.grubb@gmail.com>
Date: Mon, 7 May 2018 18:53:33 -0700 (PDT)
Raw View
------=_Part_25552_2099622031.1525744413755
Content-Type: multipart/alternative;
boundary="----=_Part_25553_792273245.1525744413755"
------=_Part_25553_792273245.1525744413755
Content-Type: text/plain; charset="UTF-8"
You are describing something like "co-variant return types", which works
for primitive types (https://godbolt.org/g/ra5rhy), but it doesn't work for
user-defined types (even shared_ptr) at all.
Your proposal seems reasonable and using a keyword would at least make it
explicit that you're opting into this behavior. I like it. Being able to
use smart_ptr's in those places would be helpful.
Jared
On Monday, May 7, 2018 at 7:59:06 AM UTC-7, volodym...@globallogic.com
wrote:
>
> Hi.
>
> If method is not virtual, you can simply "hide" it in derived class:
> struct A
> {
> void F() {}
> };
> struct B: public A
> {
> int F() { return 0; }
> };
> But if method is virtual, compiler will try to override it (instead of
> hide). In case of different result types this will leads to errors:
> struct A
> {
> virtual void F() {}
> };
> struct B: public A
> {
> int F() { return 0; } // error, different result types
> };
> In C# such things easily makes via operator "new":
> class A
> {
> public virtual void F() { }
> };
> class B: A
> {
> public new int F() { return 0; }
> }
> I propose to use the similar approach. For example operator "overload":
> struct A
> {
> virtual void F() {}
> };
> struct B: public A
> {
> int F() overload { return 0; } // error, different result types
> };
> This will let us, for example, to use covariance (in general, as approach)
> and smart pointers together:
> // interface
> struct IProduct {};
> struct IPipeline
> {
> virtual std::shared_ptr<IProduct> GetProduct();
> };
>
> // implementation
> struct Product: IProduct {};
> struct Pipeline: IPipeline
> {
> std::shared_ptr<Product> GetProduct() overload;
> };
>
> // usage
> Pipeline pipeline;
> std::shared_ptr<Product> produce = pipeline.GetProduct();
>
> Such approach may be used only in case of "overload" operator usage to
> keep backward compatibility.
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c41fe2fc-5910-4c76-b0e0-065fa160d552%40isocpp.org.
------=_Part_25553_792273245.1525744413755
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">You are describing something like "co-variant return =
types", which works for primitive types (https://godbolt.org/g/ra5rhy)=
, but it doesn't work for user-defined types (even shared_ptr) at all.<=
br><br>Your proposal seems reasonable and using a keyword would at least ma=
ke it explicit that you're opting into this behavior. I like it. Being =
able to use smart_ptr's in those places would be helpful.<br><br>Jared<=
br><br>On Monday, May 7, 2018 at 7:59:06 AM UTC-7, volodym...@globallogic.c=
om 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">Hi.<=
br><br>If method is not virtual, you can simply "hide" it in deri=
ved class:<br>struct A<br>{<br>=C2=A0=C2=A0=C2=A0 void F() {}<br>};<br>stru=
ct B: public A<br>{<br>=C2=A0=C2=A0=C2=A0 int F() { return 0; }<br>};<br>Bu=
t if method is virtual, compiler will try to override it (instead of hide).=
In case of different result types this will leads to errors:<br>struct A<b=
r>{<br>=C2=A0=C2=A0=C2=A0 virtual void F() {}<br>};<br>struct B: public A<b=
r>{<br>=C2=A0=C2=A0=C2=A0 int F() { return 0; } // error, different result =
types<br>};<br>In C# such things easily makes via operator "new":=
<br>class A<br>{<br>=C2=A0=C2=A0=C2=A0 public virtual void F() { }<br>};<br=
>class B: A<br>{<br>=C2=A0=C2=A0=C2=A0 public new int F() { return 0; }<br>=
}<br>I propose to use the similar approach. For example operator "over=
load":<br>struct A<br>{<br>=C2=A0=C2=A0=C2=A0 virtual void F() {}<br>}=
;<br>struct B: public A<br>{<br>=C2=A0=C2=A0=C2=A0 int F() overload { retur=
n 0; } // error, different result types<br>};<br>This will let us, for exam=
ple, to use covariance (in general, as approach) and smart pointers togethe=
r:<br>// interface<br>struct IProduct {};<br>struct IPipeline<br>{<br>=C2=
=A0=C2=A0=C2=A0 virtual std::shared_ptr<IProduct> GetProduct();<br>};=
<br><br>// implementation<br>struct Product: IProduct {};<br>struct Pipelin=
e: IPipeline<br>{<br>=C2=A0=C2=A0=C2=A0 std::shared_ptr<Product> GetP=
roduct() overload;<br>};<br><br>// usage<br>Pipeline pipeline;<br>std::shar=
ed_ptr<Product> produce =3D pipeline.GetProduct();<br><br>Such approa=
ch may be used only in case of "overload" operator usage to keep =
backward compatibility.<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c41fe2fc-5910-4c76-b0e0-065fa160d552%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c41fe2fc-5910-4c76-b0e0-065fa160d552=
%40isocpp.org</a>.<br />
------=_Part_25553_792273245.1525744413755--
------=_Part_25552_2099622031.1525744413755--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 07 May 2018 19:55:11 -0700
Raw View
On segunda-feira, 7 de maio de 2018 18:53:33 PDT Jared Grubb wrote:
> You are describing something like "co-variant return types", which works
> for primitive types (https://godbolt.org/g/ra5rhy), but it doesn't work for
> user-defined types (even shared_ptr) at all.
Note that the proposal would *not* be a covariant override.
In a covariant override, the override returns a new type but you can still
call the base implementation and the language will adjust pointers as
necessary to make the caller get the right object. This new override /
overload does not do that.
The proposal needs amending if this is one of the target use-cases.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2854927.TkF46kRZde%40tjmaciei-mobl1.
.
Author: "volodymyr.ryvak via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 8 May 2018 03:55:04 -0700 (PDT)
Raw View
------=_Part_26936_1070564926.1525776904570
Content-Type: multipart/alternative;
boundary="----=_Part_26937_49973100.1525776904570"
------=_Part_26937_49973100.1525776904570
Content-Type: text/plain; charset="UTF-8"
The problem with contravariant types is clear. Different smart pointers
can't be "covariant" unless one of them inheriting the other one.
This may block us if we decide to change regular pointers on smart pointers.
But this problem may be solved in another way. We may just explicitly hide
the virtual method declared in basic type. And then define a new method
(not-virtual) with the same name, but with different result type (as we do
with not-virtual methods).
Together with that, we may override this virtual method as usual in some
other base class in order to support further dynamic casting.
Example:
// interface
struct IProduct {};
struct IPipeline {
virtual std::shared_ptr<IProduct> GetProduct() = 0;
};
// implementation
struct Product: IProduct {};
struct PipelineWrapper : IPipeline {
std::shared_ptr<IProduct> GetProduct() override { // override virtual
method, return derived result
return std::make_shared<Product>();
}
};
struct Pipeline: PipelineWrapper {
std::shared_ptr<Product> GetProduct() overload { // overlap virtual
method, not overriding it
return std::make_shared<Product>();
}
};
// usage (please pay attention to the types of variables)
std::shared_ptr<Pipeline> pipeline;
std::shared_ptr<Product> produce = pipeline->GetProduct();
std::shared_ptr<IPipeline> ipipeline = pipeline;
std::shared_ptr<IProduct> iproduct = ipipeline->GetProduct();
std::shared_ptr<Product> castedProduct =
std::dynamic_pointer_cast<Product>(iproduct);
All this will help us to "emulate" the covariance behavior, even if result
types are not actually covariant.
There are also other helpful outcomes. For example, the compiler may show a
warning if we are trying to overlap not-virtual method without an
"overload" keyword (as we do with "override" keyword and virtual methods).
On Tuesday, May 8, 2018 at 4:53:33 AM UTC+3, Jared Grubb wrote:
>
> You are describing something like "co-variant return types", which works
> for primitive types (https://godbolt.org/g/ra5rhy), but it doesn't work
> for user-defined types (even shared_ptr) at all.
>
> Your proposal seems reasonable and using a keyword would at least make it
> explicit that you're opting into this behavior. I like it. Being able to
> use smart_ptr's in those places would be helpful.
>
> Jared
>
> On Monday, May 7, 2018 at 7:59:06 AM UTC-7, volodym...@globallogic.com
> wrote:
>>
>> Hi.
>>
>> If method is not virtual, you can simply "hide" it in derived class:
>> struct A
>> {
>> void F() {}
>> };
>> struct B: public A
>> {
>> int F() { return 0; }
>> };
>> But if method is virtual, compiler will try to override it (instead of
>> hide). In case of different result types this will leads to errors:
>> struct A
>> {
>> virtual void F() {}
>> };
>> struct B: public A
>> {
>> int F() { return 0; } // error, different result types
>> };
>> In C# such things easily makes via operator "new":
>> class A
>> {
>> public virtual void F() { }
>> };
>> class B: A
>> {
>> public new int F() { return 0; }
>> }
>> I propose to use the similar approach. For example operator "overload":
>> struct A
>> {
>> virtual void F() {}
>> };
>> struct B: public A
>> {
>> int F() overload { return 0; } // error, different result types
>> };
>> This will let us, for example, to use covariance (in general, as
>> approach) and smart pointers together:
>> // interface
>> struct IProduct {};
>> struct IPipeline
>> {
>> virtual std::shared_ptr<IProduct> GetProduct();
>> };
>>
>> // implementation
>> struct Product: IProduct {};
>> struct Pipeline: IPipeline
>> {
>> std::shared_ptr<Product> GetProduct() overload;
>> };
>>
>> // usage
>> Pipeline pipeline;
>> std::shared_ptr<Product> produce = pipeline.GetProduct();
>>
>> Such approach may be used only in case of "overload" operator usage to
>> keep backward compatibility.
>>
>
--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/615707aa-0f54-4549-b25d-c090005dcc9e%40isocpp.org.
------=_Part_26937_49973100.1525776904570
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The problem with contravariant types is clear. Different s=
mart pointers can't be "covariant" unless one of them inherit=
ing the other one.<br><br>This may block us if we decide to change regular =
pointers on smart pointers.<br><br>But this problem may be solved in anothe=
r way. We may just explicitly hide the virtual method declared in basic typ=
e. And then define a new method (not-virtual) with the same name, but with =
different result type (as we do with not-virtual methods).<br>Together with=
that, we may override this virtual method as usual in some other base clas=
s in order to support further dynamic casting.<br><br>Example:<br>// interf=
ace<br>struct IProduct {};<br>struct IPipeline {<br>=C2=A0=C2=A0=C2=A0 virt=
ual std::shared_ptr<IProduct> GetProduct() =3D 0;<br>};<br><br>// imp=
lementation<br>struct Product: IProduct {};<br>struct PipelineWrapper : IPi=
peline {<br>=C2=A0=C2=A0=C2=A0 std::shared_ptr<IProduct> GetProduct()=
override { // override virtual method, return derived result<br>=C2=A0=C2=
=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return std::make_shared<Product>();<br>=
=C2=A0=C2=A0=C2=A0 }<br>};<br>struct Pipeline: PipelineWrapper {<br>=C2=A0=
=C2=A0=C2=A0 std::shared_ptr<Product> GetProduct() overload { // over=
lap virtual method, not overriding it<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 return std::make_shared<Product>();<br>=C2=A0=C2=A0=C2=A0 }<br>};=
<br><br>// usage (please pay attention to the types of variables)<br>std::s=
hared_ptr<Pipeline>=C2=A0=C2=A0=C2=A0 pipeline;<br>std::shared_ptr<=
;Product>=C2=A0=C2=A0=C2=A0 produce=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 =3D pipeline->GetProduct();<br>std::shared_ptr<IP=
ipeline>=C2=A0=C2=A0=C2=A0 ipipeline=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 =3D pipeline;<br>std::shared_ptr<IProduct>=C2=A0=C2=A0=C2=A0 ipro=
duct=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =3D ipipeline->GetProduct();<b=
r>std::shared_ptr<Product>=C2=A0=C2=A0=C2=A0 castedProduct=C2=A0=C2=
=A0=C2=A0 =3D std::dynamic_pointer_cast<Product>(iproduct);<br><br>Al=
l this will help us to "emulate" the covariance behavior, even if=
result types are not actually covariant.<br>There are also other helpful o=
utcomes. For example, the compiler may show a warning if we are trying to o=
verlap not-virtual method without an "overload" keyword (as we do=
with "override" keyword and virtual methods).<br><br><br>On Tues=
day, May 8, 2018 at 4:53:33 AM UTC+3, Jared Grubb 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">You are describing something l=
ike "co-variant return types", which works for primitive types (<=
a href=3D"https://godbolt.org/g/ra5rhy" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F=
%2Fgodbolt.org%2Fg%2Fra5rhy\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHdAGJ2X=
K84V57n71IyCb4Y-qVN_Q';return true;" onclick=3D"this.href=3D'https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2Fra5rhy\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHdAGJ2XK84V57n71IyCb4Y-qVN_Q';return true=
;">https://godbolt.org/g/ra5rhy</a>)<wbr>, but it doesn't work for user=
-defined types (even shared_ptr) at all.<br><br>Your proposal seems reasona=
ble and using a keyword would at least make it explicit that you're opt=
ing into this behavior. I like it. Being able to use smart_ptr's in tho=
se places would be helpful.<br><br>Jared<br><br>On Monday, May 7, 2018 at 7=
:59:06 AM UTC-7, <a>volodym...@globallogic.com</a> wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Hi.<br><br>If method is not virtual=
, you can simply "hide" it in derived class:<br>struct A<br>{<br>=
=C2=A0=C2=A0=C2=A0 void F() {}<br>};<br>struct B: public A<br>{<br>=C2=A0=
=C2=A0=C2=A0 int F() { return 0; }<br>};<br>But if method is virtual, compi=
ler will try to override it (instead of hide). In case of different result =
types this will leads to errors:<br>struct A<br>{<br>=C2=A0=C2=A0=C2=A0 vir=
tual void F() {}<br>};<br>struct B: public A<br>{<br>=C2=A0=C2=A0=C2=A0 int=
F() { return 0; } // error, different result types<br>};<br>In C# such thi=
ngs easily makes via operator "new":<br>class A<br>{<br>=C2=A0=C2=
=A0=C2=A0 public virtual void F() { }<br>};<br>class B: A<br>{<br>=C2=A0=C2=
=A0=C2=A0 public new int F() { return 0; }<br>}<br>I propose to use the sim=
ilar approach. For example operator "overload":<br>struct A<br>{<=
br>=C2=A0=C2=A0=C2=A0 virtual void F() {}<br>};<br>struct B: public A<br>{<=
br>=C2=A0=C2=A0=C2=A0 int F() overload { return 0; } // error, different re=
sult types<br>};<br>This will let us, for example, to use covariance (in ge=
neral, as approach) and smart pointers together:<br>// interface<br>struct =
IProduct {};<br>struct IPipeline<br>{<br>=C2=A0=C2=A0=C2=A0 virtual std::sh=
ared_ptr<IProduct> GetProduct();<br>};<br><br>// implementation<br>st=
ruct Product: IProduct {};<br>struct Pipeline: IPipeline<br>{<br>=C2=A0=C2=
=A0=C2=A0 std::shared_ptr<Product> GetProduct() overload;<br>};<br><b=
r>// usage<br>Pipeline pipeline;<br>std::shared_ptr<Product> produce =
=3D pipeline.GetProduct();<br><br>Such approach may be used only in case of=
"overload" operator usage to keep backward compatibility.<br></d=
iv></blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/615707aa-0f54-4549-b25d-c090005dcc9e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/615707aa-0f54-4549-b25d-c090005dcc9e=
%40isocpp.org</a>.<br />
------=_Part_26937_49973100.1525776904570--
------=_Part_26936_1070564926.1525776904570--
.