Topic: A new stab at getting operator.() functionality:
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 19 Oct 2018 08:57:45 +0100
Raw View
--000000000000e1b1c80578904250
Content-Type: text/plain; charset="UTF-8"
On Fri, 19 Oct 2018 at 03:38, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:
> There have been multiple attempts at being able to write a general Wrapper
> class without having to explicitly write forwarding versions of each method
> in the Wrapped class.
>
Trying to create operator.() seems to me to be treating the symptom rather
than the cause.
Surely what we would all like is a language mechanism that allows us to
semantically indicate that:
"I would like X class to be a forwarding wrapper to Y impl class through Z
kind of 'ownership'"
ownership examples might be (non-exhaustive):
a unque_ptr<>
a shared_ptr<>
a reference_wrapper<>
a contained object (owner<> ?)
a boost::intrusive_ptr<>
a custom os-specific intrusive_ptr (eg when targeting COM, OSX, etc)
and so on.
I seem to remember seeing some work on metaclasses for c++, which would
completely solve this issue, as well as many others.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0707r3.pdf
> The obvious idea would be to allow operator.() to be overridden, but so
> far this road has been blocked by difficulties in how to handle collisions
> between method names in Wrapper and Wrapped.
>
> Another attempt has been to introduce an idea of inheritance by reference
> or indirect inheritance. This was shot down for philosophical reasons with
> the sentiment that the Wrapper does not represent a "is-a" relationship to
> the Wrapped object. Otherwise this has the nice property of inheriting(!)
> the rules of method hiding from regular inheritance: Any declaration in the
> "subclass" i.e. Wrapper hides the corresponding name in the "base class",
> i.e. Wrapped class. This can be overridden by using Wrapped::<name>
> notation as for any inheritance.
>
> This post is a third attempt at solving this problem: Redefine the lookup
> rules for cast operators. Currently cast operators are attempted to be able
> to pass an object as function parameter. So in the above example a Wrapper
> object can be passed to a function taking a Wrapped parameter, invoking the
> cast operator. However, this does not happen for an object where a member
> is to be accessed, so if Wrapped has a method a you can't invoke a on a
> Wrapper. This proposal is to change this so that if no method a is found in
> Wrapper a search is done in Wrapped also.
>
> Here is a simple example:
>
>
> struct A {
> void a();
> };
>
> class B {
> public:
> operator A&() { return m_a; }
>
> private:
> A m_a;
> };
>
> void fun(A& a)
> {
> }
>
> int main()
> {
> B b;
> fun(b); // Works by invoking the cast operator.
> b.a(); // Currently an error, but works with this proposal.
> }
>
> The problem of a class with multiple cast operators causing possible
> ambiguity should be solved according to the same rules as for multiple
> inheritance. Disambiguation can however not be performed using the Class::
> syntax as we are not inheriting. Instead static_cast<A&>(b).a() would be
> the way to explicitly invoke the cast operator and thus tell the compiler
> which instance of a named entity to use.
>
> I think the use cases and motivation for this proposal are well
> established as it solves the same problems that operator.() was addressing.
> The interesting question is whether there are backwards compatibility
> issues or confusion created by introducing this feature into the language.
>
>
>
> --
> 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/a195e287-a40b-458c-88be-e281c92e595d%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a195e287-a40b-458c-88be-e281c92e595d%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CALvx3hZJED%3Dhu_j0zQq6BQTo_e3MrpX6b7H5BKHi8L5ri-Rsxw%40mail.gmail.com.
--000000000000e1b1c80578904250
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Fri, 19 Oct 2018 at 03:38, Bengt Gustafsson <<a href=3D"ma=
ilto:bengt.gustafsson@beamways.com">bengt.gustafsson@beamways.com</a>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">There have been multiple attempts at being able to write a general=
Wrapper class without having to explicitly write forwarding versions of ea=
ch method in the Wrapped class.=C2=A0</div></blockquote><div><br></div><div=
>Trying to create <font face=3D"monospace, monospace">operator.()</font> se=
ems to me to be treating the symptom rather than the cause.</div><div><br><=
/div><div>Surely what we would all like is a language mechanism that allows=
us to semantically indicate that:</div><div><br></div><div>"I would l=
ike X class to be a forwarding wrapper to Y impl class through Z kind of &#=
39;ownership'"</div><div><br></div><div>ownership examples might b=
e (non-exhaustive):</div><div><br></div><div>a unque_ptr<></div><div>=
a shared_ptr<></div><div>a reference_wrapper<></div><div>a cont=
ained object (owner<> ?)</div><div>a boost::intrusive_ptr<>=C2=
=A0</div><div>a custom os-specific intrusive_ptr (eg when targeting COM, OS=
X, etc)</div><div>and so on.<br></div><div><br></div><div>=C2=A0I seem to r=
emember seeing some work on metaclasses for c++, which would completely sol=
ve this issue, as well as many others.</div><div><br></div><div><a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0707r3.pdf">http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0707r3.pdf</a><br></div>=
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div><br></div><div>The obvious idea would be to allow operator.()=
to be overridden, but so far this road has been blocked by difficulties in=
how to handle collisions between method names in Wrapper and Wrapped.</div=
><div><br></div><div>Another attempt has been to introduce an idea of inher=
itance by reference or indirect inheritance. This was shot down for philoso=
phical reasons with the sentiment that the Wrapper does not represent a &qu=
ot;is-a" relationship to the Wrapped object. Otherwise this has the ni=
ce property of inheriting(!) the rules of method hiding from regular inheri=
tance: Any declaration in the "subclass" i.e. Wrapper hides the c=
orresponding name in the "base class", i.e. Wrapped class. This c=
an be overridden by using Wrapped::<name> notation as for any inherit=
ance.</div><div><br></div><div>This post is a third attempt at solving this=
problem: Redefine the lookup rules for cast operators. Currently cast oper=
ators are attempted to be able to pass an object as function parameter. So =
in the above example a Wrapper object can be passed to a function taking a =
Wrapped parameter, invoking the cast operator. However, this does not happe=
n for an object where a member is to be accessed, so if Wrapped has a metho=
d a you can't invoke a on a Wrapper. This proposal is to change this so=
that if no method a is found in Wrapper a search is done in Wrapped also.<=
/div><div><br></div><div>Here is a simple example:</div><div><br></div><div=
><div><br><div><span style=3D"color:rgb(0,0,255)">struct</span> A {</div><d=
iv> <span style=3D"color:rgb(0,0,255)">=C2=A0 =C2=A0 void</span> a();</d=
iv><div>};</div><br><div><span style=3D"color:rgb(0,0,255)">class</span> B =
{</div><div><span style=3D"color:rgb(0,0,255)">public</span>:</div><div> =
<span style=3D"color:rgb(0,0,255)">=C2=A0 =C2=A0 operator</span> A&() =
{ <span style=3D"color:rgb(0,0,255)">return</span> m_a; }</div><br><div><sp=
an style=3D"color:rgb(0,0,255)">private</span>:</div><div>=C2=A0 =C2=A0 A m=
_a;</div><div>};</div><div><br></div><div><div><span style=3D"color:rgb(0,0=
,255)">void</span> fun(A& a)=C2=A0</div><div>{</div><div>}</div></div><=
div><br></div><div>int main()</div><div>{</div><div>=C2=A0 =C2=A0B b;</div>=
<div>=C2=A0 =C2=A0fun(b); // Works by invoking the cast operator.</div><div=
>=C2=A0 =C2=A0b.a();=C2=A0 =C2=A0// Currently an error, but works with this=
proposal.</div><div>}</div><div><br></div><div>The problem of a class with=
multiple cast operators causing possible ambiguity should be solved accord=
ing to the same rules as for multiple inheritance. Disambiguation can howev=
er not be performed using the Class:: syntax as we are not inheriting. Inst=
ead static_cast<A&>(b).a() would be the way to explicitly invoke =
the cast operator and thus tell the compiler which instance of a named enti=
ty to use.</div><div><br></div><div>I think the use cases and motivation fo=
r this proposal are well established as it solves the same problems that op=
erator.() was addressing. The interesting question is whether there are bac=
kwards compatibility issues or confusion created by introducing this featur=
e into the language.</div></div></div><div><br></div><div><br></div><div><b=
r></div></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" 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>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a195e287-a40b-458c-88be-e281c92e595d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a195e287-a40b-=
458c-88be-e281c92e595d%40isocpp.org</a>.<br>
</blockquote></div></div></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/CALvx3hZJED%3Dhu_j0zQq6BQTo_e3MrpX6b7=
H5BKHi8L5ri-Rsxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZJED%3Dh=
u_j0zQq6BQTo_e3MrpX6b7H5BKHi8L5ri-Rsxw%40mail.gmail.com</a>.<br />
--000000000000e1b1c80578904250--
.
Author: mihailnajdenov@gmail.com
Date: Fri, 19 Oct 2018 01:39:56 -0700 (PDT)
Raw View
------=_Part_2267_1824971337.1539938396411
Content-Type: multipart/alternative;
boundary="----=_Part_2268_569578320.1539938396411"
------=_Part_2268_569578320.1539938396411
Content-Type: text/plain; charset="UTF-8"
On Friday, October 19, 2018 at 5:38:27 AM UTC+3, Bengt Gustafsson wrote:
>
> There have been multiple attempts at being able to write a general Wrapper
> class without having to explicitly write forwarding versions of each method
> in the Wrapped class.
>
> The obvious idea would be to allow operator.() to be overridden, but so
> far this road has been blocked by difficulties in how to handle collisions
> between method names in Wrapper and Wrapped.
>
> Another attempt has been to introduce an idea of inheritance by reference
> or indirect inheritance. This was shot down for philosophical reasons with
> the sentiment that the Wrapper does not represent a "is-a" relationship to
> the Wrapped object. Otherwise this has the nice property of inheriting(!)
> the rules of method hiding from regular inheritance: Any declaration in the
> "subclass" i.e. Wrapper hides the corresponding name in the "base class",
> i.e. Wrapped class. This can be overridden by using Wrapped::<name>
> notation as for any inheritance.
>
> This post is a third attempt at solving this problem: Redefine the lookup
> rules for cast operators. Currently cast operators are attempted to be able
> to pass an object as function parameter. So in the above example a Wrapper
> object can be passed to a function taking a Wrapped parameter, invoking the
> cast operator. However, this does not happen for an object where a member
> is to be accessed, so if Wrapped has a method a you can't invoke a on a
> Wrapper. This proposal is to change this so that if no method a is found in
> Wrapper a search is done in Wrapped also.
>
> Here is a simple example:
>
>
> struct A {
> void a();
> };
>
> class B {
> public:
> operator A&() { return m_a; }
>
> private:
> A m_a;
> };
>
> void fun(A& a)
> {
> }
>
> int main()
> {
> B b;
> fun(b); // Works by invoking the cast operator.
> b.a(); // Currently an error, but works with this proposal.
> }
>
Something tells me this was evaluated back in the day and rejected for some
reason. Someone should remind us why.
I am afraid it might hit the same philosophical problems "of the is-a kind"
- essentially this proposal is even more bold then the one with `using`
inheritance.
As a shameless plug
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/vZti2htmrlQ/IPbrJXR8AgAJ>,
consider
struct A {
void a();
};
class B {
public:
operator A&() { return m_a; }
private:
A m_a;
};
void fun(A& a)
{
}
using A::a; //< import as free function
class B using
{
a;
}
int main()
{
B b;
fun(b); // Works by invoking the cast operator.
b.a(); //< works
a(b); //< also works
}
I am not saying this solves all needs for "operator()." (in quotes) - of
which I am a fan of, but if the issue is just the fact "conversion works
only for params",
then we could hack our way by "just" allowing function params to be passed
using member access syntax, which is essentially UCS.
We could streamline further by not needing to import as free function first
if the class has a conversion operator to the class he is importing a
function from.
class B using
{
A::a; //< allowed, B can pretend to be A
}
--
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/4c62ab82-216f-4719-9d35-e2abc5db987d%40isocpp.org.
------=_Part_2268_569578320.1539938396411
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 19, 2018 at 5:38:27 AM UTC+3, B=
engt Gustafsson 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">There have been multiple attempts at being able to write a general=
Wrapper class without having to explicitly write forwarding versions of ea=
ch method in the Wrapped class.=C2=A0<div><br></div><div>The obvious idea w=
ould be to allow operator.() to be overridden, but so far this road has bee=
n blocked by difficulties in how to handle collisions between method names =
in Wrapper and Wrapped.</div><div><br></div><div>Another attempt has been t=
o introduce an idea of inheritance by reference or indirect inheritance. Th=
is was shot down for philosophical reasons with the sentiment that the Wrap=
per does not represent a "is-a" relationship to the Wrapped objec=
t. Otherwise this has the nice property of inheriting(!) the rules of metho=
d hiding from regular inheritance: Any declaration in the "subclass&qu=
ot; i.e. Wrapper hides the corresponding name in the "base class"=
, i.e. Wrapped class. This can be overridden by using Wrapped::<name>=
notation as for any inheritance.</div><div><br></div><div>This post is a t=
hird attempt at solving this problem: Redefine the lookup rules for cast op=
erators. Currently cast operators are attempted to be able to pass an objec=
t as function parameter. So in the above example a Wrapper object can be pa=
ssed to a function taking a Wrapped parameter, invoking the cast operator. =
However, this does not happen for an object where a member is to be accesse=
d, so if Wrapped has a method a you can't invoke a on a Wrapper. This p=
roposal is to change this so that if no method a is found in Wrapper a sear=
ch is done in Wrapped also.</div><div><br></div><div>Here is a simple examp=
le:</div><div><br></div><div><div><br><div><span style=3D"color:#0000ff">st=
ruct</span> A {</div><div> <span style=3D"color:#0000ff">=C2=A0 =C2=A0 v=
oid</span> a();</div><div>};</div><br><div><span style=3D"color:#0000ff">cl=
ass</span> B {</div><div><span style=3D"color:#0000ff">public</span>:</div>=
<div> <span style=3D"color:#0000ff">=C2=A0 =C2=A0 operator</span> A&=
() { <span style=3D"color:#0000ff">return</span> m_a; }</div><br><div><span=
style=3D"color:#0000ff">private</span>:</div><div>=C2=A0 =C2=A0 A m_a;</di=
v><div>};</div><div><br></div><div><div><span style=3D"color:#0000ff">void<=
/span> fun(A& a)=C2=A0</div><div>{</div><div>}</div></div><div><br></di=
v><div>int main()</div><div>{</div><div>=C2=A0 =C2=A0B b;</div><div>=C2=A0 =
=C2=A0fun(b); // Works by invoking the cast operator.</div><div>=C2=A0 =C2=
=A0b.a();=C2=A0 =C2=A0// Currently an error, but works with this proposal.<=
/div><div>}</div></div></div></div></blockquote><div><br></div><div><br></d=
iv><div>Something tells me this was evaluated back in the day and rejected =
for some reason. Someone should remind us why.</div><div><br></div><div>I a=
m afraid it might hit the same philosophical problems "of the is-a kin=
d" - essentially this proposal is even more bold then the one with `us=
ing` inheritance.</div><div><br></div><div>=C2=A0</div><div><br></div><div>=
As a <a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/=
vZti2htmrlQ/IPbrJXR8AgAJ">shameless plug</a>, consider=C2=A0</div><div><br>=
</div><div><div><span style=3D"color: rgb(0, 0, 255);">struct</span>=C2=A0A=
{</div><div><span style=3D"color: rgb(0, 0, 255);">=C2=A0 =C2=A0 void</spa=
n>=C2=A0a();</div><div>};</div><br><div><span style=3D"color: rgb(0, 0, 255=
);">class</span>=C2=A0B {</div><div><span style=3D"color: rgb(0, 0, 255);">=
public</span>:</div><div><span style=3D"color: rgb(0, 0, 255);">=C2=A0 =C2=
=A0 operator</span>=C2=A0A&() {=C2=A0<span style=3D"color: rgb(0, 0, 25=
5);">return</span>=C2=A0m_a; }</div><br><div><span style=3D"color: rgb(0, 0=
, 255);">private</span>:</div><div>=C2=A0 =C2=A0 A m_a;</div><div>};</div><=
div><br></div><div><div><span style=3D"color: rgb(0, 0, 255);">void</span>=
=C2=A0fun(A& a)=C2=A0</div><div>{</div><div>}</div></div><div><br></div=
><div><font face=3D"courier new, monospace"><font color=3D"#0000ff">using <=
/font>A::a; <font color=3D"#38761d">//< import as free function</font></=
font></div><div><font face=3D"courier new, monospace"><br></font></div><div=
><font face=3D"courier new, monospace"><font color=3D"#0000ff">class </font=
>B <font color=3D"#0000ff">using=C2=A0</font></font></div><div><font face=
=3D"courier new, monospace">{</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 a;</font></div><div><font face=3D"courier new, monospace">=
}</font></div><div><br></div><div><font color=3D"#0000ff">int </font>main()=
</div><div>{</div><div>=C2=A0 =C2=A0B b;</div><div>=C2=A0 =C2=A0fun(b); // =
Works by invoking the cast operator.</div><div>=C2=A0 =C2=A0b.a();=C2=A0 <f=
ont color=3D"#38761d">=C2=A0//< works</font></div><div>=C2=A0 =C2=A0a(b)=
;=C2=A0 <font color=3D"#38761d">=C2=A0//< also works</font></div><div>}<=
/div></div><div><br></div><div>I am not saying this solves all needs for &q=
uot;operator()." (in quotes) - of which I am a fan of, but if the issu=
e is just the fact "conversion works only for params",=C2=A0</div=
><div>then we could hack our way by "just" allowing function para=
ms to be passed using member access syntax, which is essentially UCS.</div>=
<div><br></div><div>We could streamline further by not needing to import as=
free function first if the class has a conversion operator to the class he=
is importing a function from.=C2=A0</div><div><br></div><div><div><font fa=
ce=3D"courier new, monospace"><font color=3D"#0000ff">class=C2=A0</font>B=
=C2=A0<font color=3D"#0000ff">using=C2=A0</font></font></div><div><font fac=
e=3D"courier new, monospace">{</font></div><div><font face=3D"courier new, =
monospace">=C2=A0 A::a; <font color=3D"#38761d">//< allowed, B can prete=
nd to be A=C2=A0</font></font></div><div><font face=3D"courier new, monospa=
ce">}</font></div></div><div>=C2=A0</div></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/4c62ab82-216f-4719-9d35-e2abc5db987d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4c62ab82-216f-4719-9d35-e2abc5db987d=
%40isocpp.org</a>.<br />
------=_Part_2268_569578320.1539938396411--
------=_Part_2267_1824971337.1539938396411--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 19 Oct 2018 07:35:38 -0700 (PDT)
Raw View
------=_Part_3538_2139185607.1539959738486
Content-Type: multipart/alternative;
boundary="----=_Part_3539_1129060021.1539959738487"
------=_Part_3539_1129060021.1539959738487
Content-Type: text/plain; charset="UTF-8"
My proposed feature would give us all that you long for. For instance my B
class could just as well have been spelled:
class B {
operator A& { return *ap; }
std::shared_ptr<A> ap;
};
To get a generic wrapper with shared semantics. I think this comes much
more natural than indirect inheritance, where you still need additional
syntax to indicate how the wrapped object is to be conjured up. In this
proposal we only add a new way of finding members in case there is no
member of the specified name in the Wrapper class (B above).
Den fredag 19 oktober 2018 kl. 09:57:58 UTC+2 skrev Richard Hodges:
>
>
>
> On Fri, 19 Oct 2018 at 03:38, Bengt Gustafsson <bengt.gu...@beamways.com
> <javascript:>> wrote:
>
>> There have been multiple attempts at being able to write a general
>> Wrapper class without having to explicitly write forwarding versions of
>> each method in the Wrapped class.
>>
>
> Trying to create operator.() seems to me to be treating the symptom
> rather than the cause.
>
> Surely what we would all like is a language mechanism that allows us to
> semantically indicate that:
>
> "I would like X class to be a forwarding wrapper to Y impl class through Z
> kind of 'ownership'"
>
> ownership examples might be (non-exhaustive):
>
> a unque_ptr<>
> a shared_ptr<>
> a reference_wrapper<>
> a contained object (owner<> ?)
> a boost::intrusive_ptr<>
> a custom os-specific intrusive_ptr (eg when targeting COM, OSX, etc)
> and so on.
>
> I seem to remember seeing some work on metaclasses for c++, which would
> completely solve this issue, as well as many others.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0707r3.pdf
>
>
>> The obvious idea would be to allow operator.() to be overridden, but so
>> far this road has been blocked by difficulties in how to handle collisions
>> between method names in Wrapper and Wrapped.
>>
>> Another attempt has been to introduce an idea of inheritance by reference
>> or indirect inheritance. This was shot down for philosophical reasons with
>> the sentiment that the Wrapper does not represent a "is-a" relationship to
>> the Wrapped object. Otherwise this has the nice property of inheriting(!)
>> the rules of method hiding from regular inheritance: Any declaration in the
>> "subclass" i.e. Wrapper hides the corresponding name in the "base class",
>> i.e. Wrapped class. This can be overridden by using Wrapped::<name>
>> notation as for any inheritance.
>>
>> This post is a third attempt at solving this problem: Redefine the lookup
>> rules for cast operators. Currently cast operators are attempted to be able
>> to pass an object as function parameter. So in the above example a Wrapper
>> object can be passed to a function taking a Wrapped parameter, invoking the
>> cast operator. However, this does not happen for an object where a member
>> is to be accessed, so if Wrapped has a method a you can't invoke a on a
>> Wrapper. This proposal is to change this so that if no method a is found in
>> Wrapper a search is done in Wrapped also.
>>
>> Here is a simple example:
>>
>>
>> struct A {
>> void a();
>> };
>>
>> class B {
>> public:
>> operator A&() { return m_a; }
>>
>> private:
>> A m_a;
>> };
>>
>> void fun(A& a)
>> {
>> }
>>
>> int main()
>> {
>> B b;
>> fun(b); // Works by invoking the cast operator.
>> b.a(); // Currently an error, but works with this proposal.
>> }
>>
>> The problem of a class with multiple cast operators causing possible
>> ambiguity should be solved according to the same rules as for multiple
>> inheritance. Disambiguation can however not be performed using the Class::
>> syntax as we are not inheriting. Instead static_cast<A&>(b).a() would be
>> the way to explicitly invoke the cast operator and thus tell the compiler
>> which instance of a named entity to use.
>>
>> I think the use cases and motivation for this proposal are well
>> established as it solves the same problems that operator.() was addressing.
>> The interesting question is whether there are backwards compatibility
>> issues or confusion created by introducing this feature into the language.
>>
>>
>>
>> --
>> 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:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a195e287-a40b-458c-88be-e281c92e595d%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a195e287-a40b-458c-88be-e281c92e595d%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/16b31301-d66c-4bd4-b65a-f2cf98a9697b%40isocpp.org.
------=_Part_3539_1129060021.1539959738487
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My proposed feature would give us all that you long for. F=
or instance my B class could just as well have been spelled:<div><br></div>=
<div>class B {</div><div>=C2=A0 =C2=A0operator A& { return *ap; }</div>=
<div><br></div><div>=C2=A0 =C2=A0std::shared_ptr<A> ap;</div><div>};<=
/div><div><br></div><div>To get a generic wrapper with shared semantics. I =
think this comes much more natural than indirect inheritance, where you sti=
ll need additional syntax to indicate how the wrapped object is to be conju=
red up. In this proposal we only add a new way of finding members in case t=
here is no member of the specified name in the Wrapper class (B above).</di=
v><div><br><br>Den fredag 19 oktober 2018 kl. 09:57:58 UTC+2 skrev Richard =
Hodges:<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 d=
ir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 19 O=
ct 2018 at 03:38, Bengt Gustafsson <<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"jOD2iEwRCQAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">bengt.gu...@beamways.com</a><wbr>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">There have been multiple attempts at being able to write a general=
Wrapper class without having to explicitly write forwarding versions of ea=
ch method in the Wrapped class.=C2=A0</div></blockquote><div><br></div><div=
>Trying to create <font face=3D"monospace, monospace">operator.()</font> se=
ems to me to be treating the symptom rather than the cause.</div><div><br><=
/div><div>Surely what we would all like is a language mechanism that allows=
us to semantically indicate that:</div><div><br></div><div>"I would l=
ike X class to be a forwarding wrapper to Y impl class through Z kind of &#=
39;ownership'"</div><div><br></div><div>ownership examples might b=
e (non-exhaustive):</div><div><br></div><div>a unque_ptr<></div><div>=
a shared_ptr<></div><div>a reference_wrapper<></div><div>a cont=
ained object (owner<> ?)</div><div>a boost::intrusive_ptr<>=C2=
=A0</div><div>a custom os-specific intrusive_ptr (eg when targeting COM, OS=
X, etc)</div><div>and so on.<br></div><div><br></div><div>=C2=A0I seem to r=
emember seeing some work on metaclasses for c++, which would completely sol=
ve this issue, as well as many others.</div><div><br></div><div><a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0707r3.pdf" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%=
2Fpapers%2F2018%2Fp0707r3.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEogbP=
mxKLzVGff8QwSo-HRlRirRQ';return true;" onclick=3D"this.href=3D'http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg=
21%2Fdocs%2Fpapers%2F2018%2Fp0707r3.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNEogbPmxKLzVGff8QwSo-HRlRirRQ';return true;">http://www.open-std.or=
g/jtc1/<wbr>sc22/wg21/docs/papers/2018/<wbr>p0707r3.pdf</a><br></div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div><br></div><div>The obvious idea would be to allow operator.() to be o=
verridden, but so far this road has been blocked by difficulties in how to =
handle collisions between method names in Wrapper and Wrapped.</div><div><b=
r></div><div>Another attempt has been to introduce an idea of inheritance b=
y reference or indirect inheritance. This was shot down for philosophical r=
easons with the sentiment that the Wrapper does not represent a "is-a&=
quot; relationship to the Wrapped object. Otherwise this has the nice prope=
rty of inheriting(!) the rules of method hiding from regular inheritance: A=
ny declaration in the "subclass" i.e. Wrapper hides the correspon=
ding name in the "base class", i.e. Wrapped class. This can be ov=
erridden by using Wrapped::<name> notation as for any inheritance.</d=
iv><div><br></div><div>This post is a third attempt at solving this problem=
: Redefine the lookup rules for cast operators. Currently cast operators ar=
e attempted to be able to pass an object as function parameter. So in the a=
bove example a Wrapper object can be passed to a function taking a Wrapped =
parameter, invoking the cast operator. However, this does not happen for an=
object where a member is to be accessed, so if Wrapped has a method a you =
can't invoke a on a Wrapper. This proposal is to change this so that if=
no method a is found in Wrapper a search is done in Wrapped also.</div><di=
v><br></div><div>Here is a simple example:</div><div><br></div><div><div><b=
r><div><span style=3D"color:rgb(0,0,255)">struct</span> A {</div><div> <=
span style=3D"color:rgb(0,0,255)">=C2=A0 =C2=A0 void</span> a();</div><div>=
};</div><br><div><span style=3D"color:rgb(0,0,255)">class</span> B {</div><=
div><span style=3D"color:rgb(0,0,255)">public</span>:</div><div> <span s=
tyle=3D"color:rgb(0,0,255)">=C2=A0 =C2=A0 operator</span> A&() { <span =
style=3D"color:rgb(0,0,255)">return</span> m_a; }</div><br><div><span style=
=3D"color:rgb(0,0,255)">private</span>:</div><div>=C2=A0 =C2=A0 A m_a;</div=
><div>};</div><div><br></div><div><div><span style=3D"color:rgb(0,0,255)">v=
oid</span> fun(A& a)=C2=A0</div><div>{</div><div>}</div></div><div><br>=
</div><div>int main()</div><div>{</div><div>=C2=A0 =C2=A0B b;</div><div>=C2=
=A0 =C2=A0fun(b); // Works by invoking the cast operator.</div><div>=C2=A0 =
=C2=A0b.a();=C2=A0 =C2=A0// Currently an error, but works with this proposa=
l.</div><div>}</div><div><br></div><div>The problem of a class with multipl=
e cast operators causing possible ambiguity should be solved according to t=
he same rules as for multiple inheritance. Disambiguation can however not b=
e performed using the Class:: syntax as we are not inheriting. Instead stat=
ic_cast<A&>(b).a() would be the way to explicitly invoke the cast=
operator and thus tell the compiler which instance of a named entity to us=
e.</div><div><br></div><div>I think the use cases and motivation for this p=
roposal are well established as it solves the same problems that operator.(=
) was addressing. The interesting question is whether there are backwards c=
ompatibility issues or confusion created by introducing this feature into t=
he language.</div></div></div><div><br></div><div><br></div><div><br></div>=
</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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
jOD2iEwRCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';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"jOD2iEwRCQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@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/a195e287-a40b-458c-88be-e281c92e595d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/a195e287-a40b-458c-88be-e281c92e595d%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/a195e287-a40b-458c-88be-e281c92e595d%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a195e287-a40b-458c-<wbr>88be-=
e281c92e595d%40isocpp.org</a><wbr>.<br>
</blockquote></div></div></div>
</blockquote></div></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/16b31301-d66c-4bd4-b65a-f2cf98a9697b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16b31301-d66c-4bd4-b65a-f2cf98a9697b=
%40isocpp.org</a>.<br />
------=_Part_3539_1129060021.1539959738487--
------=_Part_3538_2139185607.1539959738486--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 19 Oct 2018 07:51:30 -0700 (PDT)
Raw View
------=_Part_189_1851651963.1539960691044
Content-Type: multipart/alternative;
boundary="----=_Part_190_967082386.1539960691045"
------=_Part_190_967082386.1539960691045
Content-Type: text/plain; charset="UTF-8"
>
> Something tells me this was evaluated back in the day and rejected for
> some reason. Someone should remind us why.
>
I have no recollection of this. But as the discussion around this feature
reach so far back I would be surprised if this was the first time the idea
came up.
>
> I am afraid it might hit the same philosophical problems "of the is-a
> kind" - essentially this proposal is even more bold then the one with
> `using` inheritance.
>
I don't see why. A cast operator does not indicate inheritance, so no is-a
promises are being made, indeed a cast operator is most easily thought of
as providing a way to unwrap something wrapped.
An alternate view on all of this would be that we remove the special case
of the LHS expression of the (built in) operator.() and operator-> does not
check for cast operators, in contrast with all other binary operators. I
was uncertain so I tried that this works:
int operator*(const A& rhs) { return 3; }
B b;
*b; // Calls operator above after calling cast operator.
(https://godbolt.org/z/BN77df)
I don't entirely follow your shamelessly plugged code, but you mention UCS
(unified call syntax), which of course makes this case fairly odd, unless
this proposal is accepted:
a(b); // May work via UCS in case it is acceptable to first call a cast
operator on b before calling its method a. This is unclear and may be one
of the contentious points with UCS.
b.a(); // Does not work with UCS unless this proposal is accepted.
void c(A& a);
c(b); // Works as always, by using the cast operator from B to A&
b.c(); // Probably works with UCS only.
My comments on this are that with UCS and not this proposal we get into a
strange land where it is unclear which of the four calls above are valid.
With both UCS and this proposal all would surely be valid. Saying that this
is not needed if we get UCS is not true, and apart from that UCS has also
been rejected so far.
>
>
> As a shameless plug
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/vZti2htmrlQ/IPbrJXR8AgAJ>,
> consider
>
> struct A {
> void a();
> };
>
> class B {
> public:
> operator A&() { return m_a; }
>
> private:
> A m_a;
> };
>
> void fun(A& a)
> {
> }
>
> using A::a; //< import as free function
>
> class B using
> {
> a;
> }
>
> int main()
> {
> B b;
> fun(b); // Works by invoking the cast operator.
> b.a(); //< works
> a(b); //< also works
> }
>
> I am not saying this solves all needs for "operator()." (in quotes) - of
> which I am a fan of, but if the issue is just the fact "conversion works
> only for params",
> then we could hack our way by "just" allowing function params to be passed
> using member access syntax, which is essentially UCS.
>
> We could streamline further by not needing to import as free function
> first if the class has a conversion operator to the class he is importing a
> function from.
>
> I don't understand what you intend the A::a; syntax below to mean.
> class B using
> {
> A::a; //< allowed, B can pretend to be A
> }
>
>
--
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/410f61f2-ce98-4714-a81d-199b26bfca89%40isocpp.org.
------=_Part_190_967082386.1539960691045
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>Something tells me this was evaluated back in the day and rejected=
for some reason. Someone should remind us why.</div></div></blockquote><di=
v>I have no recollection of this. But as the discussion around this feature=
reach so far back I would be surprised if this was the first time the idea=
came up.</div><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><br></div><div>I am afraid it might hit the same philosophical probl=
ems "of the is-a kind" - essentially this proposal is even more b=
old then the one with `using` inheritance.</div></div></blockquote><div>I d=
on't see why. A cast operator does not indicate inheritance, so no is-a=
promises are being made, indeed a cast operator is most easily thought of =
as providing a way to unwrap something wrapped.</div><div><br></div><div>An=
alternate view on all of this would be that we remove the special case of =
the LHS expression of the (built in) operator.() and operator-> does not=
check for cast operators, in contrast with all other binary operators. I w=
as uncertain so I tried that this works:</div><div><br></div><div><div styl=
e=3D"color: #000000;background-color: #fffffe;font-family: Consolas, " libe=
ration=3D"" mono",=3D"" courier,=3D"" monospace;font-weight:=3D"" normal;fo=
nt-size:=3D"" 14px;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D""><spa=
n style=3D"color: #0000ff;">int</span> <span style=3D"color: #0000ff;">oper=
ator</span>*(<span style=3D"color: #0000ff;">const</span> A& rhs) { <sp=
an style=3D"color: #0000ff;">return</span> <span style=3D"color: #09885a;">=
3</span>; }</div></div><div style=3D"color: #000000;background-color: #ffff=
fe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" monos=
pace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19px;w=
hite-space:=3D"" pre;"=3D""><br></div><div style=3D"color: #000000;backgrou=
nd-color: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" cour=
ier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-heig=
ht:=3D"" 19px;white-space:=3D"" pre;"=3D"">B b;</div><div style=3D"color: #=
000000;background-color: #fffffe;font-family: Consolas, " liberation=3D"" m=
ono",=3D"" courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D""=
14px;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D"">*b;=C2=A0 // Call=
s operator above after calling cast operator.</div><div style=3D"color: #00=
0000;background-color: #fffffe;font-family: Consolas, " liberation=3D"" mon=
o",=3D"" courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 1=
4px;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D""><br></div><div styl=
e=3D"color: #000000;background-color: #fffffe;font-family: Consolas, " libe=
ration=3D"" mono",=3D"" courier,=3D"" monospace;font-weight:=3D"" normal;fo=
nt-size:=3D"" 14px;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D"">(htt=
ps://godbolt.org/z/BN77df)</div><div style=3D"color: #000000;background-col=
or: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=
=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=
=3D"" 19px;white-space:=3D"" pre;"=3D""><br></div><div style=3D"color: #000=
000;background-color: #fffffe;font-family: Consolas, " liberation=3D"" mono=
",=3D"" courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14=
px;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D"">I don't entirely=
follow your shamelessly plugged code, but you mention UCS (unified call sy=
ntax), which of course makes this case fairly odd, unless this proposal is =
accepted:</div><div style=3D"color: #000000;background-color: #fffffe;font-=
family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" monospace;fon=
t-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19px;white-spa=
ce:=3D"" pre;"=3D""><br></div><div style=3D"color: #000000;background-color=
: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"=
" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D""=
19px;white-space:=3D"" pre;"=3D"">a(b);=C2=A0 =C2=A0 =C2=A0// May work via=
UCS in case it is acceptable to first call a cast operator on b before cal=
ling its method a. This is unclear and may be one of the contentious points=
with UCS.</div><div style=3D"color: #000000;background-color: #fffffe;font=
-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" monospace;fo=
nt-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19px;white-sp=
ace:=3D"" pre;"=3D"">b.a();=C2=A0 =C2=A0 // Does not work with UCS unless t=
his proposal is accepted.</div><div style=3D"color: #000000;background-colo=
r: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D=
"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"=
" 19px;white-space:=3D"" pre;"=3D""><br></div><div style=3D"color: #000000;=
background-color: #fffffe;font-family: Consolas, " liberation=3D"" mono",=
=3D"" courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px=
;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D"">void c(A& a);</div=
><div style=3D"color: #000000;background-color: #fffffe;font-family: Consol=
as, " liberation=3D"" mono",=3D"" courier,=3D"" monospace;font-weight:=3D""=
normal;font-size:=3D"" 14px;line-height:=3D"" 19px;white-space:=3D"" pre;"=
=3D""><br></div><div style=3D"color: #000000;background-color: #fffffe;font=
-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" monospace;fo=
nt-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 19px;white-sp=
ace:=3D"" pre;"=3D"">c(b);=C2=A0 =C2=A0 =C2=A0// Works as always, by using =
the cast operator from B to A&</div><div style=3D"color: #000000;backgr=
ound-color: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" co=
urier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-he=
ight:=3D"" 19px;white-space:=3D"" pre;"=3D"">b.c();=C2=A0 =C2=A0 // Probabl=
y works with UCS only.</div><div style=3D"color: #000000;background-color: =
#fffffe;font-family: Consolas, " liberation=3D"" mono",=3D"" courier,=3D"" =
monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line-height:=3D"" 1=
9px;white-space:=3D"" pre;"=3D""><br></div><div style=3D"color: #000000;bac=
kground-color: #fffffe;font-family: Consolas, " liberation=3D"" mono",=3D""=
courier,=3D"" monospace;font-weight:=3D"" normal;font-size:=3D"" 14px;line=
-height:=3D"" 19px;white-space:=3D"" pre;"=3D"">My comments on this are tha=
t with UCS and not this proposal we get into a strange land where it is unc=
lear which of the four calls above are valid. With both UCS and this propos=
al all would surely be valid. Saying that this is not needed if we get UCS =
is not true, and apart from that UCS has also been rejected so far.</div><d=
iv style=3D"color: #000000;background-color: #fffffe;font-family: Consolas,=
" liberation=3D"" mono",=3D"" courier,=3D"" monospace;font-weight:=3D"" no=
rmal;font-size:=3D"" 14px;line-height:=3D"" 19px;white-space:=3D"" pre;"=3D=
""><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><br></div><div>=C2=A0</div><div><br></div><div>As a <a =
href=3D"https://groups.google.com/a/isocpp.org/d/msg/std-proposals/vZti2htm=
rlQ/IPbrJXR8AgAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'https://groups.google.com/a/isocpp.org/d/msg/std-proposals/vZti2h=
tmrlQ/IPbrJXR8AgAJ';return true;" onclick=3D"this.href=3D'https://g=
roups.google.com/a/isocpp.org/d/msg/std-proposals/vZti2htmrlQ/IPbrJXR8AgAJ&=
#39;;return true;">shameless plug</a>, consider=C2=A0</div><div><br></div><=
div><div><span style=3D"color:rgb(0,0,255)">struct</span>=C2=A0A {</div><di=
v><span style=3D"color:rgb(0,0,255)">=C2=A0 =C2=A0 void</span>=C2=A0a();</d=
iv><div>};</div><br><div><span style=3D"color:rgb(0,0,255)">class</span>=C2=
=A0B {</div><div><span style=3D"color:rgb(0,0,255)">public</span>:</div><di=
v><span style=3D"color:rgb(0,0,255)">=C2=A0 =C2=A0 operator</span>=C2=A0A&a=
mp;() {=C2=A0<span style=3D"color:rgb(0,0,255)">return</span>=C2=A0m_a; }</=
div><br><div><span style=3D"color:rgb(0,0,255)">private</span>:</div><div>=
=C2=A0 =C2=A0 A m_a;</div><div>};</div><div><br></div><div><div><span style=
=3D"color:rgb(0,0,255)">void</span>=C2=A0fun(A& a)=C2=A0</div><div>{</d=
iv><div>}</div></div><div><br></div><div><font face=3D"courier new, monospa=
ce"><font color=3D"#0000ff">using </font>A::a; <font color=3D"#38761d">//&l=
t; import as free function</font></font></div><div><font face=3D"courier ne=
w, monospace"><br></font></div><div><font face=3D"courier new, monospace"><=
font color=3D"#0000ff">class </font>B <font color=3D"#0000ff">using=C2=A0</=
font></font></div><div><font face=3D"courier new, monospace">{</font></div>=
<div><font face=3D"courier new, monospace">=C2=A0 a;</font></div><div><font=
face=3D"courier new, monospace">}</font></div><div><br></div><div><font co=
lor=3D"#0000ff">int </font>main()</div><div>{</div><div>=C2=A0 =C2=A0B b;</=
div><div>=C2=A0 =C2=A0fun(b); // Works by invoking the cast operator.</div>=
<div>=C2=A0 =C2=A0b.a();=C2=A0 <font color=3D"#38761d">=C2=A0//< works</=
font></div><div>=C2=A0 =C2=A0a(b);=C2=A0 <font color=3D"#38761d">=C2=A0//&l=
t; also works</font></div><div>}</div></div><div><br></div><div>I am not sa=
ying this solves all needs for "operator()." (in quotes) - of whi=
ch I am a fan of, but if the issue is just the fact "conversion works =
only for params",=C2=A0</div><div>then we could hack our way by "=
just" allowing function params to be passed using member access syntax=
, which is essentially UCS.</div><div><br></div><div>We could streamline fu=
rther by not needing to import as free function first if the class has a co=
nversion operator to the class he is importing a function from.=C2=A0</div>=
<div><br></div></div></blockquote><div>I don't understand what you inte=
nd the A::a; syntax below to mean.=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;"><div dir=3D"ltr"><div></div><div><div><font face=3D"courier=
new, monospace"><font color=3D"#0000ff">class=C2=A0</font>B=C2=A0<font col=
or=3D"#0000ff">using=C2=A0</font></font></div><div><font face=3D"courier ne=
w, monospace">{</font></div><div><font face=3D"courier new, monospace">=C2=
=A0 A::a; <font color=3D"#38761d">//< allowed, B can pretend to be A=C2=
=A0</font></font></div><div><font face=3D"courier new, monospace">}</font><=
/div></div><div>=C2=A0</div></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/410f61f2-ce98-4714-a81d-199b26bfca89%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/410f61f2-ce98-4714-a81d-199b26bfca89=
%40isocpp.org</a>.<br />
------=_Part_190_967082386.1539960691045--
------=_Part_189_1851651963.1539960691044--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 19 Oct 2018 07:55:46 -0700 (PDT)
Raw View
------=_Part_3576_1023970721.1539960946685
Content-Type: multipart/alternative;
boundary="----=_Part_3577_620541047.1539960946685"
------=_Part_3577_620541047.1539960946685
Content-Type: text/plain; charset="UTF-8"
On Thursday, October 18, 2018 at 9:38:27 PM UTC-5, Bengt Gustafsson wrote:
>
> This post is a third attempt at solving this problem: Redefine the lookup
> rules for cast operators. Currently cast operators are attempted to be able
> to pass an object as function parameter. So in the above example a Wrapper
> object can be passed to a function taking a Wrapped parameter, invoking the
> cast operator. However, this does not happen for an object where a member
> is to be accessed, so if Wrapped has a method a you can't invoke a on a
> Wrapper. This proposal is to change this so that if no method a is found in
> Wrapper a search is done in Wrapped also.
>
This seems like it's exactly Bjarne and Gaby's operator.() proposal, except
you're spelling it operator A&() instead of A& operator.()
--
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/4dc2a29b-2624-4ebd-a8ba-bb82a918aa75%40isocpp.org.
------=_Part_3577_620541047.1539960946685
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 18, 2018 at 9:38:27 PM UTC-5,=
Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>This post is a third attempt at solving this problem: Redef=
ine the lookup rules for cast operators. Currently cast operators are attem=
pted to be able to pass an object as function parameter. So in the above ex=
ample a Wrapper object can be passed to a function taking a Wrapped paramet=
er, invoking the cast operator. However, this does not happen for an object=
where a member is to be accessed, so if Wrapped has a method a you can'=
;t invoke a on a Wrapper. This proposal is to change this so that if no met=
hod a is found in Wrapper a search is done in Wrapped also.</div></div></bl=
ockquote><div><br></div><div>This seems like it's exactly Bjarne and Ga=
by's operator.() proposal, except you're spelling it <font face=3D"=
courier new, monospace">operator A&()</font> instead of <font face=3D"c=
ourier new, monospace">A& operator.()</font></div></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/4dc2a29b-2624-4ebd-a8ba-bb82a918aa75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4dc2a29b-2624-4ebd-a8ba-bb82a918aa75=
%40isocpp.org</a>.<br />
------=_Part_3577_620541047.1539960946685--
------=_Part_3576_1023970721.1539960946685--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 19 Oct 2018 08:22:23 -0700 (PDT)
Raw View
------=_Part_3683_721301376.1539962543205
Content-Type: multipart/alternative;
boundary="----=_Part_3684_194411629.1539962543205"
------=_Part_3684_194411629.1539962543205
Content-Type: text/plain; charset="UTF-8"
One difference may be that this proposal more naturally extends to ptr->x
which was one of the problems with operator.(). As we can already overload
operator-> we can't use that to overload it in this new way (well we could,
but the effect would be to not be able to reach Wrapper methods via a
Wrapper*). With this proposal it is the searching rules for members that
are changed, no new operators are involved, so these rules would naturally
work equally for . and ->
This proposal also handles multiple cast operators, by using an "as if"
rule for the lookup: As-if the Wrapper inherited from all of them (after
removing references of course). To avoid backwards compatibility issues the
cast operators would only be tried if the member name was not found in any
of the real base classes of the Wrapper. While this rule may seem less than
optimal it seems the only backwards compatible path forward: Only if the
current rules result in a lookup error are the cast operators considered.
Den fredag 19 oktober 2018 kl. 16:55:46 UTC+2 skrev Barry Revzin:
>
>
>
> On Thursday, October 18, 2018 at 9:38:27 PM UTC-5, Bengt Gustafsson wrote:
>>
>> This post is a third attempt at solving this problem: Redefine the lookup
>> rules for cast operators. Currently cast operators are attempted to be able
>> to pass an object as function parameter. So in the above example a Wrapper
>> object can be passed to a function taking a Wrapped parameter, invoking the
>> cast operator. However, this does not happen for an object where a member
>> is to be accessed, so if Wrapped has a method a you can't invoke a on a
>> Wrapper. This proposal is to change this so that if no method a is found in
>> Wrapper a search is done in Wrapped also.
>>
>
> This seems like it's exactly Bjarne and Gaby's operator.() proposal,
> except you're spelling it operator A&() instead of A& operator.()
>
--
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/6793597b-148f-41b8-8f1f-85233c93f755%40isocpp.org.
------=_Part_3684_194411629.1539962543205
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">One difference may be that this proposal more naturally ex=
tends to ptr->x which was one of the problems with operator.(). As we ca=
n already overload operator-> we can't use that to overload it in th=
is new way (well we could, but the effect would be to not be able to reach =
Wrapper methods via a Wrapper*). With this proposal it is the searching rul=
es for members that are changed, no new operators are involved, so these ru=
les would naturally work equally for . and -><div><br></div><div>This pr=
oposal also handles multiple cast operators, by using an "as if" =
rule for the lookup: As-if the Wrapper inherited from all of them (after re=
moving references of course). To avoid backwards compatibility issues the c=
ast operators would only be tried if the member name was not found in any o=
f the real base classes of the Wrapper. While this rule may seem less than =
optimal it seems the only backwards compatible path forward: Only if the cu=
rrent rules result in a lookup error are the cast operators considered.<br>=
<div><br></div><div><br><br>Den fredag 19 oktober 2018 kl. 16:55:46 UTC+2 s=
krev Barry Revzin:<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"><br><br>On Thursday, October 18, 2018 at 9:38:27 PM UTC-5, Bengt Gusta=
fsson 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>T=
his post is a third attempt at solving this problem: Redefine the lookup ru=
les for cast operators. Currently cast operators are attempted to be able t=
o pass an object as function parameter. So in the above example a Wrapper o=
bject can be passed to a function taking a Wrapped parameter, invoking the =
cast operator. However, this does not happen for an object where a member i=
s to be accessed, so if Wrapped has a method a you can't invoke a on a =
Wrapper. This proposal is to change this so that if no method a is found in=
Wrapper a search is done in Wrapped also.</div></div></blockquote><div><br=
></div><div>This seems like it's exactly Bjarne and Gaby's operator=
..() proposal, except you're spelling it <font face=3D"courier new, mono=
space">operator A&()</font> instead of <font face=3D"courier new, monos=
pace">A& operator.()</font></div></div></blockquote></div></div></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/6793597b-148f-41b8-8f1f-85233c93f755%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6793597b-148f-41b8-8f1f-85233c93f755=
%40isocpp.org</a>.<br />
------=_Part_3684_194411629.1539962543205--
------=_Part_3683_721301376.1539962543205--
.
Author: mihailnajdenov@gmail.com
Date: Fri, 19 Oct 2018 09:02:21 -0700 (PDT)
Raw View
------=_Part_3586_711065873.1539964941570
Content-Type: multipart/alternative;
boundary="----=_Part_3587_288919299.1539964941570"
------=_Part_3587_288919299.1539964941570
Content-Type: text/plain; charset="UTF-8"
On Friday, October 19, 2018 at 6:22:23 PM UTC+3, Bengt Gustafsson wrote:
>
> One difference may be that this proposal more naturally extends to ptr->x
> which was one of the problems with operator.(). As we can already overload
> operator-> we can't use that to overload it in this new way (well we could,
> but the effect would be to not be able to reach Wrapper methods via a
> Wrapper*). With this proposal it is the searching rules for members that
> are changed, no new operators are involved, so these rules would naturally
> work equally for . and ->
>
> This proposal also handles multiple cast operators, by using an "as if"
> rule for the lookup: As-if the Wrapper inherited from all of them (after
> removing references of course). To avoid backwards compatibility issues the
> cast operators would only be tried if the member name was not found in any
> of the real base classes of the Wrapper. While this rule may seem less than
> optimal it seems the only backwards compatible path forward: Only if the
> current rules result in a lookup error are the cast operators considered.
>
Looks to me, this will result to the same issue that UCS faced, in
particular adding methods to the wrapper - it can change behavior of
wrapped objects.
struct A
{
int count();
};
template<class T>
struct W
{
operator T&() {return *a;}
int count(); //< may be later, hides the A::count for all users that use
A via W<A>
private:
T* a;
}
>
>
>
> Den fredag 19 oktober 2018 kl. 16:55:46 UTC+2 skrev Barry Revzin:
>>
>>
>>
>> On Thursday, October 18, 2018 at 9:38:27 PM UTC-5, Bengt Gustafsson wrote:
>>>
>>> This post is a third attempt at solving this problem: Redefine the
>>> lookup rules for cast operators. Currently cast operators are attempted to
>>> be able to pass an object as function parameter. So in the above example a
>>> Wrapper object can be passed to a function taking a Wrapped parameter,
>>> invoking the cast operator. However, this does not happen for an object
>>> where a member is to be accessed, so if Wrapped has a method a you can't
>>> invoke a on a Wrapper. This proposal is to change this so that if no method
>>> a is found in Wrapper a search is done in Wrapped also.
>>>
>>
>> This seems like it's exactly Bjarne and Gaby's operator.() proposal,
>> except you're spelling it operator A&() instead of A& operator.()
>>
>
--
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/557a5e50-ba1a-4ef0-94c4-5c9cc056148d%40isocpp.org.
------=_Part_3587_288919299.1539964941570
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, October 19, 2018 at 6:22:23 PM UTC+3, B=
engt Gustafsson 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">One difference may be that this proposal more naturally extends to=
ptr->x which was one of the problems with operator.(). As we can alread=
y overload operator-> we can't use that to overload it in this new w=
ay (well we could, but the effect would be to not be able to reach Wrapper =
methods via a Wrapper*). With this proposal it is the searching rules for m=
embers that are changed, no new operators are involved, so these rules woul=
d naturally work equally for . and -><div><br></div><div>This proposal a=
lso handles multiple cast operators, by using an "as if" rule for=
the lookup: As-if the Wrapper inherited from all of them (after removing r=
eferences of course). To avoid backwards compatibility issues the cast oper=
ators would only be tried if the member name was not found in any of the re=
al base classes of the Wrapper. While this rule may seem less than optimal =
it seems the only backwards compatible path forward: Only if the current ru=
les result in a lookup error are the cast operators considered.<br></div></=
div></blockquote><div><br></div><div>Looks to me, this will result to the s=
ame issue that UCS faced, in particular adding methods to the wrapper - it =
can change behavior of wrapped objects.</div><div><font face=3D"courier new=
, monospace"><br></font></div><div><font face=3D"courier new, monospace">st=
ruct A</font></div><div><font face=3D"courier new, monospace">{</font></div=
><div><font face=3D"courier new, monospace">=C2=A0 int count();</font></div=
><div><font face=3D"courier new, monospace">};</font></div><div><font face=
=3D"courier new, monospace">template<class T></font></div><div><font =
face=3D"courier new, monospace">struct W</font></div><div><font face=3D"cou=
rier new, monospace">{</font></div><div><font face=3D"courier new, monospac=
e">=C2=A0 operator T&() {return *a;}=C2=A0</font></div><div><font face=
=3D"courier new, monospace"><br></font></div><div><font face=3D"courier new=
, monospace">=C2=A0 int count(); //< may be later, hides the A::count fo=
r all users that use A via W<A></font></div><div><font face=3D"courie=
r new, monospace">private:=C2=A0</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 T* a;</font></div><div><font face=3D"courier new, monos=
pace">}=C2=A0=C2=A0</font></div><div><br></div><div><br></div><div>=C2=A0</=
div><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><div=
><br></div><div><br><br>Den fredag 19 oktober 2018 kl. 16:55:46 UTC+2 skrev=
Barry Revzin:<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"><br>=
<br>On Thursday, October 18, 2018 at 9:38:27 PM UTC-5, Bengt Gustafsson wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>This post =
is a third attempt at solving this problem: Redefine the lookup rules for c=
ast operators. Currently cast operators are attempted to be able to pass an=
object as function parameter. So in the above example a Wrapper object can=
be passed to a function taking a Wrapped parameter, invoking the cast oper=
ator. However, this does not happen for an object where a member is to be a=
ccessed, so if Wrapped has a method a you can't invoke a on a Wrapper. =
This proposal is to change this so that if no method a is found in Wrapper =
a search is done in Wrapped also.</div></div></blockquote><div><br></div><d=
iv>This seems like it's exactly Bjarne and Gaby's operator.() propo=
sal, except you're spelling it <font face=3D"courier new, monospace">op=
erator A&()</font> instead of <font face=3D"courier new, monospace">A&a=
mp; operator.()</font></div></div></blockquote></div></div></div></blockquo=
te></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/557a5e50-ba1a-4ef0-94c4-5c9cc056148d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/557a5e50-ba1a-4ef0-94c4-5c9cc056148d=
%40isocpp.org</a>.<br />
------=_Part_3587_288919299.1539964941570--
------=_Part_3586_711065873.1539964941570--
.