------=_Part_1002_1420469326.1498581155607
Content-Type: multipart/alternative;
 boundary="----=_Part_1003_795100258.1498581155607"

------=_Part_1003_795100258.1498581155607
Content-Type: text/plain; charset="UTF-8"

Stroustrup's P0700 (PDF) <http://wg21.link/P0700> paper is a critique of P0352:
Smart References through Delegation (PDF) <http://wg21.link/P0352>. As the
author of the direct proposal for operator-dot P0416 (PDF)
<http://wg21.link/P0416>, naturally Stroustrup doesn't have a particularly
high opinion of P0352.

It's an interesting paper. Essentially, the foundational idea of P0352 is
that you can achieve 99% of the goals of operator-dot without all of the
baggage that operator-dot requires. You express it by piggy-backing off of
inheritance; the proxied type is a base class of the proxy, except that it
is not a base class *subobject*. The conversion from the proxy to the "base
class" is user-provided rather than through the usual base class means.

This means that we don't have to rewrite the rules of what `x.y` means.
Such an expression uses the exact same rules of lookup we currently have
now. `x.y` would first look through derived class members, then base
classes, and so forth.

Stroustrup's argument against P0352 is essentially that P0352 is all about
the technical challenge (or specifically, about *avoiding* the technical
challenge) of providing the functionality, rather than just rewriting
whatever rules in C++ need to be rewritten. That is, if you have an
overload of operator-dot, then you *want* `x.y` to always look `y` up in
the proxied type.

Stroustrup has a point, with regard to P0352's lack of discussion of the
usability of the proxy types it creates. However, I find that Stroustrup's
argument misses one key point with regard to usability: the number of rules
users have to know.

See, it's not a question of whether `++x` calls the proxy or the proxied
type. To me, it's a question of *why* it calls that. Or more to the point,
how easy it is to realize that `x.y` will call a member of the proxied type
rather than the proxy.

With P0416, operator-dot, I now have to remember a bunch of new lookup
rules. I have to check to see if a type overloads operator-dot. If it does,
then I have to know exactly what the new rules are, that the proxied type
takes priority. But these rules are complicated. There are times when the
proxied type doesn't take priority (if I recall correctly, in constructors
and destructors).  And more importantly, if I really want to access the
proxy rather than the proxied type, I have to learn a complex new idiom:
`std::addressof(x)->y`.

The advantage of P0352 is that I *don't* have new rules to learn. `x.y`
follows C++ lookup rules that have existed since the day C++ was
standardized. The derived class overrides the base class names. That's the
rule, and we all know it by heart. So the proxy takes priority. And if you
want to ensure access to proxied members, we already have an idiom for
that: `x.ProxiedType::y`. That's all well understood C++, and requires no
extension to the rules to achieve.

This is the "simplicity" of P0352 that Stroustrup did not seem to grasp.
Now, it may not matter much to the average user in the field, since in many
cases, both features will do the same thing. But in cases where there are
genuine questions about which members are accessed, it is better to have
one set of rules than to have two. And also, when it comes to implementing
proxies, I think it will be very crucial to users to have an intuitive
understanding of what their code is supposed to mean.

Though admittedly, I personally *despise* the P0416 design that gives the
proxied type priority in every case (and I'm not a fan of overloading
operator-dot to begin with). So that may just be my personal desire to see
us gain this functionality in a way that doesn't require me to use
`std::addressof` to access the proxy itself (particularly in its
implementation).

--
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/57d46356-3774-4c42-8ed5-2ffd369cca45%40isocpp.org.

------=_Part_1003_795100258.1498581155607
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Stroustrup&#39;s <a href=3D"http://wg21.link/P0700">P0700 =
(PDF)</a> paper is a critique of <a href=3D"http://wg21.link/P0352">P0352: =
Smart References through Delegation (PDF)</a>. As the author of the <a href=
=3D"http://wg21.link/P0416">direct proposal for operator-dot P0416 (PDF)</a=
>, naturally Stroustrup doesn&#39;t have a particularly high opinion of P03=
52.<br><br>It&#39;s an interesting paper. Essentially, the foundational ide=
a of P0352 is that you can achieve 99% of the goals of operator-dot without=
 all of the baggage that operator-dot requires. You express it by piggy-bac=
king off of inheritance; the proxied type is a base class of the proxy, exc=
ept that it is not a base class <i>subobject</i>. The conversion from the p=
roxy to the &quot;base class&quot; is user-provided rather than through the=
 usual base class means.<br><br>This means that we don&#39;t have to rewrit=
e the rules of what `x.y` means. Such an expression uses the exact same rul=
es of lookup we currently have now. `x.y` would first look through derived =
class members, then base classes, and so forth.<br><br>Stroustrup&#39;s arg=
ument against P0352 is essentially that P0352 is all about the technical ch=
allenge (or specifically, about <i>avoiding</i> the technical challenge) of=
 providing the functionality, rather than just rewriting whatever rules in =
C++ need to be rewritten. That is, if you have an overload of operator-dot,=
 then you <i>want</i> `x.y` to always look `y` up in the proxied type.<br><=
br>Stroustrup has a point, with regard to P0352&#39;s lack of discussion of=
 the usability of the proxy types it creates. However, I find that Stroustr=
up&#39;s argument misses one key point with regard to usability: the number=
 of rules users have to know.<br><br>See, it&#39;s not a question of whethe=
r `++x` calls the proxy or the proxied type. To me, it&#39;s a question of =
<i>why</i> it calls that. Or more to the point, how easy it is to realize t=
hat `x.y` will call a member of the proxied type rather than the proxy.<br>=
<br>With P0416, operator-dot, I now have to remember a bunch of new lookup =
rules. I have to check to see if a type overloads operator-dot. If it does,=
 then I have to know exactly what the new rules are, that the proxied type =
takes priority. But these rules are complicated. There are times when the p=
roxied type doesn&#39;t take priority (if I recall correctly, in constructo=
rs and destructors).=C2=A0 And more importantly, if I really want to access=
 the proxy rather than the proxied type, I have to learn a complex new idio=
m: `std::addressof(x)-&gt;y`.<br><br>The advantage of P0352 is that I <i>do=
n&#39;t</i> have new rules to learn. `x.y` follows C++ lookup rules that ha=
ve existed since the day C++ was standardized. The derived class overrides =
the base class names. That&#39;s the rule, and we all know it by heart. So =
the proxy takes priority. And if you want to ensure access to proxied membe=
rs, we already have an idiom for that: `x.ProxiedType::y`. That&#39;s all w=
ell understood C++, and requires no extension to the rules to achieve.<br><=
br>This is the &quot;simplicity&quot; of P0352 that Stroustrup did not seem=
 to grasp. Now, it may not matter much to the average user in the field, si=
nce in many cases, both features will do the same thing. But in cases where=
 there are genuine questions about which members are accessed, it is better=
 to have one set of rules than to have two. And also, when it comes to impl=
ementing proxies, I think it will be very crucial to users to have an intui=
tive understanding of what their code is supposed to mean.<br><br>Though ad=
mittedly, I personally <i>despise</i> the P0416 design that gives the proxi=
ed type priority in every case (and I&#39;m not a fan of overloading operat=
or-dot to begin with). So that may just be my personal desire to see us gai=
n this functionality in a way that doesn&#39;t require me to use `std::addr=
essof` to access the proxy itself (particularly in its implementation).<br>=
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/57d46356-3774-4c42-8ed5-2ffd369cca45%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/57d46356-3774-4c42-8ed5-2ffd369cca45=
%40isocpp.org</a>.<br />

------=_Part_1003_795100258.1498581155607--

------=_Part_1002_1420469326.1498581155607--

.

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

I had a proposal for operator dot as well, P0060,  but I just gave up on it
since P0352 is just so much nicer: it just works.
Adopting it should be a no-brainer.

The other proposals just add a ton of complications and have a number of
corner cases where they don't work as expected and don't satisfy the
principle of least surprise.

A number of people on the committee seem to believe that adding complexity
to the language is not a problem so long as that complexity is not exposed
to the "everyday programmer". I think that's a terrible approach since any
serious C++ developer, expert or not, needs to precisely understand what
the code they're looking at is doing.
Consistent and simple rules go a long way, and inheritance has everything
that we need already.

On 27 Jun 2017 5:32 pm, "Nicol Bolas" <jmckesson@gmail.com> wrote:

Stroustrup's P0700 (PDF) <http://wg21.link/P0700> paper is a critique of P0352:
Smart References through Delegation (PDF) <http://wg21.link/P0352>. As the
author of the direct proposal for operator-dot P0416 (PDF)
<http://wg21.link/P0416>, naturally Stroustrup doesn't have a particularly
high opinion of P0352.

It's an interesting paper. Essentially, the foundational idea of P0352 is
that you can achieve 99% of the goals of operator-dot without all of the
baggage that operator-dot requires. You express it by piggy-backing off of
inheritance; the proxied type is a base class of the proxy, except that it
is not a base class *subobject*. The conversion from the proxy to the "base
class" is user-provided rather than through the usual base class means.

This means that we don't have to rewrite the rules of what `x.y` means.
Such an expression uses the exact same rules of lookup we currently have
now. `x.y` would first look through derived class members, then base
classes, and so forth.

Stroustrup's argument against P0352 is essentially that P0352 is all about
the technical challenge (or specifically, about *avoiding* the technical
challenge) of providing the functionality, rather than just rewriting
whatever rules in C++ need to be rewritten. That is, if you have an
overload of operator-dot, then you *want* `x.y` to always look `y` up in
the proxied type.

Stroustrup has a point, with regard to P0352's lack of discussion of the
usability of the proxy types it creates. However, I find that Stroustrup's
argument misses one key point with regard to usability: the number of rules
users have to know.

See, it's not a question of whether `++x` calls the proxy or the proxied
type. To me, it's a question of *why* it calls that. Or more to the point,
how easy it is to realize that `x.y` will call a member of the proxied type
rather than the proxy.

With P0416, operator-dot, I now have to remember a bunch of new lookup
rules. I have to check to see if a type overloads operator-dot. If it does,
then I have to know exactly what the new rules are, that the proxied type
takes priority. But these rules are complicated. There are times when the
proxied type doesn't take priority (if I recall correctly, in constructors
and destructors).  And more importantly, if I really want to access the
proxy rather than the proxied type, I have to learn a complex new idiom:
`std::addressof(x)->y`.

The advantage of P0352 is that I *don't* have new rules to learn. `x.y`
follows C++ lookup rules that have existed since the day C++ was
standardized. The derived class overrides the base class names. That's the
rule, and we all know it by heart. So the proxy takes priority. And if you
want to ensure access to proxied members, we already have an idiom for
that: `x.ProxiedType::y`. That's all well understood C++, and requires no
extension to the rules to achieve.

This is the "simplicity" of P0352 that Stroustrup did not seem to grasp.
Now, it may not matter much to the average user in the field, since in many
cases, both features will do the same thing. But in cases where there are
genuine questions about which members are accessed, it is better to have
one set of rules than to have two. And also, when it comes to implementing
proxies, I think it will be very crucial to users to have an intuitive
understanding of what their code is supposed to mean.

Though admittedly, I personally *despise* the P0416 design that gives the
proxied type priority in every case (and I'm not a fan of overloading
operator-dot to begin with). So that may just be my personal desire to see
us gain this functionality in a way that doesn't require me to use
`std::addressof` to access the proxy itself (particularly in its
implementation).

--
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/57d46356-3774-4c42-
8ed5-2ffd369cca45%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/57d46356-3774-4c42-8ed5-2ffd369cca45%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/CALnjya-0Rpgfz1MC%3DtmGKfKt-5azD3twvZ%2BBYYHehSKX41MbEA%40mail.gmail.com.

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

<div dir=3D"auto"><div>I had a proposal for operator dot as well, P0060, =
=C2=A0but I just gave up on it since P0352 is just so much nicer: it just w=
orks.</div><div dir=3D"auto">Adopting it should be a no-brainer.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">The other proposals just add a ton=
 of complications and have a number of corner cases where they don&#39;t wo=
rk as expected and don&#39;t satisfy the principle of least surprise.</div>=
<div dir=3D"auto"><br></div><div dir=3D"auto">A number of people on the com=
mittee seem to believe that adding complexity to the language is not a prob=
lem so long as that complexity is not exposed to the &quot;everyday program=
mer&quot;. I think that&#39;s a terrible approach since any serious C++ dev=
eloper, expert or not, needs to precisely understand what the code they&#39=
;re looking at is doing.</div><div dir=3D"auto">Consistent and simple rules=
 go a long way, and inheritance has everything that we need already.<br><di=
v class=3D"gmail_extra" dir=3D"auto"><br><div class=3D"gmail_quote">On 27 J=
un 2017 5:32 pm, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckesson@gm=
ail.com">jmckesson@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockq=
uote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Stroustrup&#39;s <a href=3D"http://wg21.=
link/P0700" target=3D"_blank">P0700 (PDF)</a> paper is a critique of <a hre=
f=3D"http://wg21.link/P0352" target=3D"_blank">P0352: Smart References thro=
ugh Delegation (PDF)</a>. As the author of the <a href=3D"http://wg21.link/=
P0416" target=3D"_blank">direct proposal for operator-dot P0416 (PDF)</a>, =
naturally Stroustrup doesn&#39;t have a particularly high opinion of P0352.=
<br><br>It&#39;s an interesting paper. Essentially, the foundational idea o=
f P0352 is that you can achieve 99% of the goals of operator-dot without al=
l of the baggage that operator-dot requires. You express it by piggy-backin=
g off of inheritance; the proxied type is a base class of the proxy, except=
 that it is not a base class <i>subobject</i>. The conversion from the prox=
y to the &quot;base class&quot; is user-provided rather than through the us=
ual base class means.<br><br>This means that we don&#39;t have to rewrite t=
he rules of what `x.y` means. Such an expression uses the exact same rules =
of lookup we currently have now. `x.y` would first look through derived cla=
ss members, then base classes, and so forth.<br><br>Stroustrup&#39;s argume=
nt against P0352 is essentially that P0352 is all about the technical chall=
enge (or specifically, about <i>avoiding</i> the technical challenge) of pr=
oviding the functionality, rather than just rewriting whatever rules in C++=
 need to be rewritten. That is, if you have an overload of operator-dot, th=
en you <i>want</i> `x.y` to always look `y` up in the proxied type.<br><br>=
Stroustrup has a point, with regard to P0352&#39;s lack of discussion of th=
e usability of the proxy types it creates. However, I find that Stroustrup&=
#39;s argument misses one key point with regard to usability: the number of=
 rules users have to know.<br><br>See, it&#39;s not a question of whether `=
++x` calls the proxy or the proxied type. To me, it&#39;s a question of <i>=
why</i> it calls that. Or more to the point, how easy it is to realize that=
 `x.y` will call a member of the proxied type rather than the proxy.<br><br=
>With P0416, operator-dot, I now have to remember a bunch of new lookup rul=
es. I have to check to see if a type overloads operator-dot. If it does, th=
en I have to know exactly what the new rules are, that the proxied type tak=
es priority. But these rules are complicated. There are times when the prox=
ied type doesn&#39;t take priority (if I recall correctly, in constructors =
and destructors).=C2=A0 And more importantly, if I really want to access th=
e proxy rather than the proxied type, I have to learn a complex new idiom: =
`std::addressof(x)-&gt;y`.<br><br>The advantage of P0352 is that I <i>don&#=
39;t</i> have new rules to learn. `x.y` follows C++ lookup rules that have =
existed since the day C++ was standardized. The derived class overrides the=
 base class names. That&#39;s the rule, and we all know it by heart. So the=
 proxy takes priority. And if you want to ensure access to proxied members,=
 we already have an idiom for that: `x.ProxiedType::y`. That&#39;s all well=
 understood C++, and requires no extension to the rules to achieve.<br><br>=
This is the &quot;simplicity&quot; of P0352 that Stroustrup did not seem to=
 grasp. Now, it may not matter much to the average user in the field, since=
 in many cases, both features will do the same thing. But in cases where th=
ere are genuine questions about which members are accessed, it is better to=
 have one set of rules than to have two. And also, when it comes to impleme=
nting proxies, I think it will be very crucial to users to have an intuitiv=
e understanding of what their code is supposed to mean.<br><br>Though admit=
tedly, I personally <i>despise</i> the P0416 design that gives the proxied =
type priority in every case (and I&#39;m not a fan of overloading operator-=
dot to begin with). So that may just be my personal desire to see us gain t=
his functionality in a way that doesn&#39;t require me to use `std::address=
of` to access the proxy itself (particularly in its implementation).<font c=
olor=3D"#888888"><br></font></div><font color=3D"#888888">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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/57d46356-3774-4c42-8ed5-2ffd369cca45%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/57d4=
6356-3774-4c42-<wbr>8ed5-2ffd369cca45%40isocpp.org</a><wbr>.<br>
</font></blockquote></div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya-0Rpgfz1MC%3DtmGKfKt-5azD3twvZ=
%2BBYYHehSKX41MbEA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya-0Rpgf=
z1MC%3DtmGKfKt-5azD3twvZ%2BBYYHehSKX41MbEA%40mail.gmail.com</a>.<br />

--94eb2c0b8eee557bd60552f64c71--

.

--f403045d990078ad9b0552f716a2
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <mathias.gaunard@gmail.com>
wrote:

> A number of people on the committee seem to believe that adding complexity
> to the language is not a problem so long as that complexity is not exposed
> to the "everyday programmer". I think that's a terrible approach since any
> serious C++ developer, expert or not, needs to precisely understand what
> the code they're looking at is doing.
>

Yes, I also hate that kind of argument with a passion. It's just a license
to make inconsistent and confusing rules under the guise of being
"intuitive". Wanting simple or at the very least consistent rules is how to
make the language easier to reason about.

--
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/CANh8DEnUDuKOmgy8HQ%3D9uveJA0YxKfbGfdWPzmaz_Oa5_o9Pjw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mathias.gaunard@gmail.com" target=3D"_blank">mathias.gaunard@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
auto"><div>A number of people on the committee seem to believe that adding =
complexity to the language is not a problem so long as that complexity is n=
ot exposed to the &quot;everyday programmer&quot;. I think that&#39;s a ter=
rible approach since any serious C++ developer, expert or not, needs to pre=
cisely understand what the code they&#39;re looking at is doing.</div></div=
></blockquote><div><br></div><div>Yes, I also hate that kind of argument wi=
th a passion. It&#39;s just a license to make inconsistent and confusing ru=
les under the guise of being &quot;intuitive&quot;. Wanting simple or at th=
e very least consistent rules is how to make the language easier to reason =
about.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh8DEnUDuKOmgy8HQ%3D9uveJA0YxKfbGfd=
WPzmaz_Oa5_o9Pjw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnUDuKOmg=
y8HQ%3D9uveJA0YxKfbGfdWPzmaz_Oa5_o9Pjw%40mail.gmail.com</a>.<br />

--f403045d990078ad9b0552f716a2--

.

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

On Tue, Jun 27, 2017 at 4:41 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <
> mathias.gaunard@gmail.com> wrote:
> Yes, I also hate that kind of argument with a passion. It's just a license
> to make inconsistent and confusing rules under the guise of being
> "intuitive". Wanting simple or at the very least consistent rules is how to
> make the language easier to reason about.
>

It never worked for me when I was trying to convince people that strict
left-to-right order of evaluation was simple and consistent.
Instead we got the rule that makes a = b, a + b, and a << b all have
different order requirements.  P0352 seems really nice and clean to me.

--
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/CAHSYqdY6mqMvd_Y5S0w%2BghuhGatjuD0x%2B6gVXXGdxmjC36_fAw%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jun 27, 2017 at 4:41 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard =
- Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@is=
ocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><span class=3D"">On Tue, Jun 27, 2017 at 3:44=
 PM, Mathias Gaunard <span dir=3D"ltr">&lt;<a href=3D"mailto:mathias.gaunar=
d@gmail.com" target=3D"_blank">mathias.gaunard@gmail.com</a>&gt;</span> wro=
te:</span><div>Yes, I also hate that kind of argument with a passion. It&#3=
9;s just a license to make inconsistent and confusing rules under the guise=
 of being &quot;intuitive&quot;. Wanting simple or at the very least consis=
tent rules is how to make the language easier to reason about.</div></div><=
/div></div></blockquote><div><br>It never worked for me when I was trying t=
o convince people that strict left-to-right order of evaluation was simple =
and consistent.<br>Instead we got the rule that makes <font face=3D"monospa=
ce, monospace">a =3D b</font>, <font face=3D"monospace, monospace">a + b</f=
ont>, and <font face=3D"monospace, monospace">a &lt;&lt; b</font> all have =
different order requirements.=C2=A0 P0352 seems really nice and clean to me=
..</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY6mqMvd_Y5S0w%2BghuhGatjuD0x%2=
B6gVXXGdxmjC36_fAw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHSYqdY6mqMv=
d_Y5S0w%2BghuhGatjuD0x%2B6gVXXGdxmjC36_fAw%40mail.gmail.com</a>.<br />

--94eb2c190040b41e400552f7e60d--

.

------=_Part_2562_1744291528.1498603206137
Content-Type: multipart/alternative;
 boundary="----=_Part_2563_2044234625.1498603206137"

------=_Part_2563_2044234625.1498603206137
Content-Type: text/plain; charset="UTF-8"

On Tuesday, June 27, 2017 at 3:44:42 PM UTC-4, Mathias Gaunard wrote:
>
> I had a proposal for operator dot as well, P0060,  but I just gave up on
> it since P0352 is just so much nicer: it just works.
> Adopting it should be a no-brainer.
>
> The other proposals just add a ton of complications and have a number of
> corner cases where they don't work as expected and don't satisfy the
> principle of least surprise.
>

I think Stroustrup would say that "expected" and "surprise" is in the eye
of the beholder. That the beholder in this case should expect `Ref<X>` to
behave exactly like `X`, unless either special syntax is used or `X` just
doesn't have that particular behavior.

*Personally*, I think that's the wrong beholder to be looking at.
Especially when you're *implementing* the `Ref` class itself; I think it's
absolutely ridiculous to require using `std::addressof(*this)` just to
access *your own* members.

A number of people on the committee seem to believe that adding complexity
> to the language is not a problem so long as that complexity is not exposed
> to the "everyday programmer". I think that's a terrible approach since any
> serious C++ developer, expert or not, needs to precisely understand what
> the code they're looking at is doing.
>

I don't think that every C++ programmer needs to *precisely* understand
every aspect of their code (don't get me wrong; that would be a *good thing*;
I just don't think it's absolutely essential). But I do agree that a
feature which significantly magnifies the complexity of an already complex
part of the language (ie: name lookup), over a few corner cases (ie:
conflict between `X` and `Ref<X>`) is wrongheaded.

I think another pernicious problem with some committee members is an
over-reliance on caring about what the user sees rather than what the
implementer has to do. That is, the notion that the writers of code that
implement a feature in a class should be assumed to be experts, while we
should assume that the users of the class are not experts or even
knowledgable about C++. This justifies make a feature arcane for the
implementer of a type (see `std::addressof`).

Consistent and simple rules go a long way, and inheritance has everything
> that we need already.
>

To be fair, that rather depends on the goal. If the goal is for `Ref<X>` to
give absolute primacy to `X`'s interface, then inheritance cannot do that.
The question is whether this one corner case is important enough to create
a complex series of rules to gain this behavior.

I also think that simple rules can create useful effects that we didn't
intend. For example, `operator-dot` cannot allow an object to proxy
*multiple* objects; multiple inheritance through `using` declarations and
multiple conversion operators can. Indeed, it's theoretically possible to
create a proxy `variant` that exposes the interface of all of its members.
You can't do that with `operator-dot`, since that would require overloading
on `operator.()`'s return value.

--
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/c93d7f21-4bc3-45a7-b209-be1184948d32%40isocpp.org.

------=_Part_2563_2044234625.1498603206137
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 27, 2017 at 3:44:42 PM UTC-4, Mathias Gau=
nard 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"auto"><=
div>I had a proposal for operator dot as well, P0060, =C2=A0but I just gave=
 up on it since P0352 is just so much nicer: it just works.</div><div dir=
=3D"auto">Adopting it should be a no-brainer.</div><div dir=3D"auto"><br></=
div><div dir=3D"auto">The other proposals just add a ton of complications a=
nd have a number of corner cases where they don&#39;t work as expected and =
don&#39;t satisfy the principle of least surprise.</div></div></blockquote>=
<div><br>I think Stroustrup would say that &quot;expected&quot; and &quot;s=
urprise&quot; is in the eye of the beholder. That the beholder in this case=
 should expect `Ref&lt;X&gt;` to behave exactly like `X`, unless either spe=
cial syntax is used or `X` just doesn&#39;t have that particular behavior.<=
br><br><i>Personally</i>, I think that&#39;s the wrong beholder to be looki=
ng at. Especially when you&#39;re <i>implementing</i> the `Ref` class itsel=
f; I think it&#39;s absolutely ridiculous to require using `std::addressof(=
*this)` just to access <i>your own</i> members.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto"></div><d=
iv dir=3D"auto">A number of people on the committee seem to believe that ad=
ding complexity to the language is not a problem so long as that complexity=
 is not exposed to the &quot;everyday programmer&quot;. I think that&#39;s =
a terrible approach since any serious C++ developer, expert or not, needs t=
o precisely understand what the code they&#39;re looking at is doing.</div>=
</div></blockquote><div><br>I don&#39;t think that every C++ programmer nee=
ds to <i>precisely</i> understand every aspect of their code (don&#39;t get=
 me wrong; that would be a <i>good thing</i>; I just don&#39;t think it&#39=
;s absolutely essential). But I do agree that a feature which significantly=
 magnifies the complexity of an already complex part of the language (ie: n=
ame lookup), over a few corner cases (ie: conflict between `X` and `Ref&lt;=
X&gt;`) is wrongheaded.<br><br>I think another pernicious problem with some=
 committee members is an over-reliance on caring about what the user sees r=
ather than what the implementer has to do. That is, the notion that the wri=
ters of code that implement a feature in a class should be assumed to be ex=
perts, while we should assume that the users of the class are not experts o=
r even knowledgable about C++. This justifies make a feature arcane for the=
 implementer of a type (see `std::addressof`).<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto">Consisten=
t and simple rules go a long way, and inheritance has everything that we ne=
ed already.<br></div></div></blockquote><div><br>To be fair, that rather de=
pends on the goal. If the goal is for `Ref&lt;X&gt;` to give absolute prima=
cy to `X`&#39;s interface, then inheritance cannot do that. The question is=
 whether this one corner case is important enough to create a complex serie=
s of rules to gain this behavior.<br><br>I also think that simple rules can=
 create useful effects that we didn&#39;t intend. For example, `operator-do=
t` cannot allow an object to proxy <i>multiple</i> objects; multiple inheri=
tance through `using` declarations and multiple conversion operators can. I=
ndeed, it&#39;s theoretically possible to create a proxy `variant` that exp=
oses the interface of all of its members. You can&#39;t do that with `opera=
tor-dot`, since that would require overloading on `operator.()`&#39;s retur=
n value.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c93d7f21-4bc3-45a7-b209-be1184948d32%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c93d7f21-4bc3-45a7-b209-be1184948d32=
%40isocpp.org</a>.<br />

------=_Part_2563_2044234625.1498603206137--

------=_Part_2562_1744291528.1498603206137--

.

------=_Part_2452_578717011.1498605338263
Content-Type: multipart/alternative;
 boundary="----=_Part_2453_700156994.1498605338263"

------=_Part_2453_700156994.1498605338263
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wrote:
>
> On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <mathias...@gmail.com=20
> <javascript:>> wrote:
>
>> A number of people on the committee seem to believe that adding=20
>> complexity to the language is not a problem so long as that complexity i=
s=20
>> not exposed to the "everyday programmer". I think that's a terrible=20
>> approach since any serious C++ developer, expert or not, needs to precis=
ely=20
>> understand what the code they're looking at is doing.
>>
>
> Yes, I also hate that kind of argument with a passion. It's just a licens=
e=20
> to make inconsistent and confusing rules under the guise of being=20
> "intuitive". Wanting simple or at the very least consistent rules is how =
to=20
> make the language easier to reason about.
>

Hear, hear.  I have not followed operator.() very closely because it=20
generally does not matter to me, but I confess I found P0352R1 remarkably=
=20
easy to grasp, and P0700 remarkably petty and=20
whatever-the-word-is-for-not-making-a-valid-point.  Plus, on the technical=
=20
merits, if typical *usage* of the feature doesn't involve the . character=
=20
(but rather ++a and such other examples from the paper), I see no reason=20
the feature should be defined with the syntax operator.. If the feature=20
*acts* fundamentally like a user-defined type-conversion, I really really=
=20
like the idea of *spelling* it like one.

One thing that I did take from Stroustrup's P0700, though, is that I'm=20
still confused about what the desired behavior is if I have

template<class T> void f(T t);
void g(Ref<X> r);
Ref<X> rx;
f(rx);  // deduce T=3DRef<X> or just X?
g(rx);  // pass a copy of rx, or pass Ref<X>(X(rx))?
auto r2 =3D rx;  // deduce Ref<X> or just X?

I would *hope* that the desired behavior is "the former, not the latter" in=
=20
each case, but that seems too... reasonable?  I mean, isn't the whole point=
=20
of operator.() to create confusion about what is and what isn't a reference=
?

One nice thing about P0352, that I might see a use for, is that it=20
apparently re-enables the ability to "inherit from" final classes. A few=20
nifty metaprogramming techniques went out the window with the introduction=
=20
of the final qualifier, because you could no longer use the "inherit from=
=20
user-defined T" trick to get T's members into the same scope as some other=
=20
member of your own devising. But with P0352, we can get all those=20
mechanisms back easily; final classes no longer have absolute power over=20
library writers.

struct SpecialSnowflake final { };

struct Ha_Ha : public using SpecialSnowflake {
    SpecialSnowflake fake_base;
    operator SpecialSnowflake& () { return fake_base; }
};

=E2=80=93Arthur

*C++:* You accidentally create a dozen instances of yourself and shoot them=
=20
all in the foot. Providing emergency medical care is impossible since you=
=20
can't tell which are bitwise copies and which are just pointing at others=
=20
and saying "that's me, over there."

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/35d2f989-1938-4288-89f4-114985039272%40isocpp.or=
g.

------=_Part_2453_700156994.1498605338263
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabr=
ese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gauna=
rd <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"FIuITlBHAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">mathias...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"auto"><div>A number of people on the comm=
ittee seem to believe that adding complexity to the language is not a probl=
em so long as that complexity is not exposed to the &quot;everyday programm=
er&quot;. I think that&#39;s a terrible approach since any serious C++ deve=
loper, expert or not, needs to precisely understand what the code they&#39;=
re looking at is doing.</div></div></blockquote><div><br></div><div>Yes, I =
also hate that kind of argument with a passion. It&#39;s just a license to =
make inconsistent and confusing rules under the guise of being &quot;intuit=
ive&quot;. Wanting simple or at the very least consistent rules is how to m=
ake the language easier to reason about.</div></div></div></div></blockquot=
e><div><br></div><div>Hear, hear. =C2=A0I have not followed operator.() ver=
y closely because it generally does not matter to me, but I confess I found=
 P0352R1 remarkably easy to grasp, and P0700 remarkably petty and whatever-=
the-word-is-for-not-making-a-valid-point. =C2=A0Plus, on the technical meri=
ts, if typical=C2=A0<i>usage</i> of the feature doesn&#39;t involve the <fo=
nt face=3D"courier new, monospace">.</font> character (but rather <font fac=
e=3D"courier new, monospace">++a</font> and such other examples from the pa=
per), I see no reason the feature should be defined with the syntax <font f=
ace=3D"courier new, monospace">operator.</font>. If the feature <i>acts</i>=
 fundamentally like a user-defined type-conversion, I really really like th=
e idea of <i>spelling</i> it like one.</div><div><br></div><div>One thing t=
hat I did take from Stroustrup&#39;s P0700, though, is that I&#39;m still c=
onfused about what the desired behavior is if I have</div><div><br></div><d=
iv><font face=3D"courier new, monospace">template&lt;class T&gt; void f(T t=
);</font></div><div><font face=3D"courier new, monospace">void g(Ref&lt;X&g=
t; r);</font></div><div><font face=3D"courier new, monospace">Ref&lt;X&gt; =
rx;</font></div><div><font face=3D"courier new, monospace">f(rx); =C2=A0// =
deduce T=3DRef&lt;X&gt; or just X?</font></div><div><font face=3D"courier n=
ew, monospace">g(rx); =C2=A0// pass a copy of rx, or pass Ref&lt;X&gt;(X(rx=
))?</font></div><div><font face=3D"courier new, monospace">auto r2 =3D rx; =
=C2=A0// deduce Ref&lt;X&gt; or just X?</font></div><div><br></div><div>I w=
ould <i>hope</i> that the desired behavior is &quot;the former, not the lat=
ter&quot; in each case, but that seems too... reasonable? =C2=A0I mean, isn=
&#39;t the whole point of operator.() to create confusion about what is and=
 what isn&#39;t a reference?</div><div><br></div><div>One nice thing about =
P0352, that I might see a use for, is that it apparently re-enables the abi=
lity to &quot;inherit from&quot; final classes. A few nifty metaprogramming=
 techniques went out the window with the introduction of the final qualifie=
r, because you could no longer use the &quot;inherit from user-defined T&qu=
ot; trick to get T&#39;s members into the same scope as some other member o=
f your own devising. But with P0352, we can get all those mechanisms back e=
asily; final classes no longer have absolute power over library writers.</d=
iv><div><br></div><div><font face=3D"courier new, monospace">struct Special=
Snowflake final { };</font></div><div><font face=3D"courier new, monospace"=
><br></font></div><div><font face=3D"courier new, monospace">struct Ha_Ha :=
 public using SpecialSnowflake {</font></div><div><font face=3D"courier new=
, monospace">=C2=A0 =C2=A0 SpecialSnowflake fake_base;</font></div><div><fo=
nt face=3D"courier new, monospace">=C2=A0 =C2=A0 operator SpecialSnowflake&=
amp; () { return fake_base; }</font></div><div><font face=3D"courier new, m=
onospace">};</font></div><div><br></div><div>=E2=80=93Arthur</div><div><br>=
</div><div><dl style=3D"color: rgb(0, 0, 0); font-family: Georgia, Garamond=
, Palatino, &#39;Times New Roman&#39;, times, serif; font-size: 16px; text-=
align: justify;"><dd style=3D"max-width: 36em;"><b>C++:</b> You accidentall=
y create a dozen instances of yourself and shoot them all in the foot. Prov=
iding emergency medical care is impossible since you can&#39;t tell which a=
re bitwise copies and which are just pointing at others and saying &quot;th=
at&#39;s me, over there.&quot;</dd></dl></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/35d2f989-1938-4288-89f4-114985039272%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/35d2f989-1938-4288-89f4-114985039272=
%40isocpp.org</a>.<br />

------=_Part_2453_700156994.1498605338263--

------=_Part_2452_578717011.1498605338263--

.

--f403045eb5bccd2e680552f95398
Content-Type: text/plain; charset="UTF-8"

On 27 June 2017 at 23:40, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> I think Stroustrup would say that "expected" and "surprise" is in the eye
> of the beholder. That the beholder in this case should expect `Ref<X>` to
> behave exactly like `X`, unless either special syntax is used or `X` just
> doesn't have that particular behavior.
>

There is no such thing as a type behaving exactly like another type in C++,
since lookup depends on type equality and not just structural equality.

--
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/CALnjya9BZCMyWZP%3DMp8R1UXOh12HfUA9OY0ECpNrbhdM%2BfRriA%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
7 June 2017 at 23:40, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>I think St=
roustrup would say that &quot;expected&quot; and &quot;surprise&quot; is in=
 the eye of the beholder. That the beholder in this case should expect `Ref=
&lt;X&gt;` to behave exactly like `X`, unless either special syntax is used=
 or `X` just doesn&#39;t have that particular behavior.<br></div></div></bl=
ockquote><div><br></div><div>There is no such thing as a type behaving exac=
tly like another type in C++, since lookup depends on type equality and not=
 just structural equality.</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya9BZCMyWZP%3DMp8R1UXOh12HfUA9OY=
0ECpNrbhdM%2BfRriA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya9BZCMy=
WZP%3DMp8R1UXOh12HfUA9OY0ECpNrbhdM%2BfRriA%40mail.gmail.com</a>.<br />

--f403045eb5bccd2e680552f95398--

.

------=_Part_2643_1735758419.1498606089229
Content-Type: multipart/alternative;
 boundary="----=_Part_2644_661884124.1498606089229"

------=_Part_2644_661884124.1498606089229
Content-Type: text/plain; charset="UTF-8"



On Tuesday, June 27, 2017 at 7:15:38 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wrote:
>>
>> On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <mathias...@gmail.com>
>> wrote:
>>
>>> A number of people on the committee seem to believe that adding
>>> complexity to the language is not a problem so long as that complexity is
>>> not exposed to the "everyday programmer". I think that's a terrible
>>> approach since any serious C++ developer, expert or not, needs to precisely
>>> understand what the code they're looking at is doing.
>>>
>>
>> Yes, I also hate that kind of argument with a passion. It's just a
>> license to make inconsistent and confusing rules under the guise of being
>> "intuitive". Wanting simple or at the very least consistent rules is how to
>> make the language easier to reason about.
>>
>
> Hear, hear.  I have not followed operator.() very closely because it
> generally does not matter to me, but I confess I found P0352R1 remarkably
> easy to grasp, and P0700 remarkably petty and
> whatever-the-word-is-for-not-making-a-valid-point.  Plus, on the technical
> merits, if typical *usage* of the feature doesn't involve the . character
> (but rather ++a and such other examples from the paper), I see no reason
> the feature should be defined with the syntax operator.. If the feature
> *acts* fundamentally like a user-defined type-conversion, I really really
> like the idea of *spelling* it like one.
>
> One thing that I did take from Stroustrup's P0700, though, is that I'm
> still confused about what the desired behavior is if I have
>
> template<class T> void f(T t);
> void g(Ref<X> r);
> Ref<X> rx;
> f(rx);  // deduce T=Ref<X> or just X?
> g(rx);  // pass a copy of rx, or pass Ref<X>(X(rx))?
> auto r2 = rx;  // deduce Ref<X> or just X?
>
> I would *hope* that the desired behavior is "the former, not the latter"
> in each case, but that seems too... reasonable?  I mean, isn't the whole
> point of operator.() to create confusion about what is and what isn't a
> reference?
>

Well, the P0416 paper says "When  we  pass  a  smart  reference as  a
template  argument  or  initialize  an auto
object,  we  must  decide which type to deduce to: the handle or the value?
We deduce to the handle."

Also, we already have a paper to allow the latter <http://wg21.link/P0672>
(at least, for the `auto r2 = rx;` case), so we don't need this feature to
cause the former.

One nice thing about P0352, that I might see a use for, is that it
> apparently re-enables the ability to "inherit from" final classes. A few
> nifty metaprogramming techniques went out the window with the introduction
> of the final qualifier, because you could no longer use the "inherit from
> user-defined T" trick to get T's members into the same scope as some other
> member of your own devising. But with P0352, we can get all those
> mechanisms back easily; final classes no longer have absolute power over
> library writers.
>

I don't think P0352 should allow that. If a class is declared `final`, it
seems decidedly poor form for us to allow it to be used as a base class,
even if it is not a base class subobject. I mean, you can decide that
class-scoped `final` is a bad idea, but if we're going to have it, it
should actually *work*.

--
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/dae5c070-c9f9-445e-915e-6189772622c4%40isocpp.org.

------=_Part_2644_661884124.1498606089229
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 27, 2017 at 7:15:38 PM UTC-4, Art=
hur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <span dir=
=3D"ltr">&lt;<a rel=3D"nofollow">mathias...@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>A number of peopl=
e on the committee seem to believe that adding complexity to the language i=
s not a problem so long as that complexity is not exposed to the &quot;ever=
yday programmer&quot;. I think that&#39;s a terrible approach since any ser=
ious C++ developer, expert or not, needs to precisely understand what the c=
ode they&#39;re looking at is doing.</div></div></blockquote><div><br></div=
><div>Yes, I also hate that kind of argument with a passion. It&#39;s just =
a license to make inconsistent and confusing rules under the guise of being=
 &quot;intuitive&quot;. Wanting simple or at the very least consistent rule=
s is how to make the language easier to reason about.</div></div></div></di=
v></blockquote><div><br></div><div>Hear, hear. =C2=A0I have not followed op=
erator.() very closely because it generally does not matter to me, but I co=
nfess I found P0352R1 remarkably easy to grasp, and P0700 remarkably petty =
and whatever-the-word-is-for-not-<wbr>making-a-valid-point. =C2=A0Plus, on =
the technical merits, if typical=C2=A0<i>usage</i> of the feature doesn&#39=
;t involve the <font face=3D"courier new, monospace">.</font> character (bu=
t rather <font face=3D"courier new, monospace">++a</font> and such other ex=
amples from the paper), I see no reason the feature should be defined with =
the syntax <font face=3D"courier new, monospace">operator.</font>. If the f=
eature <i>acts</i> fundamentally like a user-defined type-conversion, I rea=
lly really like the idea of <i>spelling</i> it like one.</div><div><br></di=
v><div>One thing that I did take from Stroustrup&#39;s P0700, though, is th=
at I&#39;m still confused about what the desired behavior is if I have</div=
><div><br></div><div><font face=3D"courier new, monospace">template&lt;clas=
s T&gt; void f(T t);</font></div><div><font face=3D"courier new, monospace"=
>void g(Ref&lt;X&gt; r);</font></div><div><font face=3D"courier new, monosp=
ace">Ref&lt;X&gt; rx;</font></div><div><font face=3D"courier new, monospace=
">f(rx); =C2=A0// deduce T=3DRef&lt;X&gt; or just X?</font></div><div><font=
 face=3D"courier new, monospace">g(rx); =C2=A0// pass a copy of rx, or pass=
 Ref&lt;X&gt;(X(rx))?</font></div><div><font face=3D"courier new, monospace=
">auto r2 =3D rx; =C2=A0// deduce Ref&lt;X&gt; or just X?</font></div><div>=
<br></div><div>I would <i>hope</i> that the desired behavior is &quot;the f=
ormer, not the latter&quot; in each case, but that seems too... reasonable?=
 =C2=A0I mean, isn&#39;t the whole point of operator.() to create confusion=
 about what is and what isn&#39;t a reference?</div></div></blockquote><div=
><br>Well, the P0416 paper says &quot;When=C2=A0 we=C2=A0 pass=C2=A0 a=C2=
=A0 smart=C2=A0 reference as=C2=A0 a=C2=A0 template=C2=A0 argument=C2=A0 or=
=C2=A0 initialize=C2=A0 an auto<br>object,=C2=A0 we=C2=A0 must=C2=A0 decide=
 which type to deduce to: the handle or the value? We deduce to the handle.=
&quot;<br><br>Also, we already have <a href=3D"http://wg21.link/P0672">a pa=
per to allow the latter</a> (at least, for the `auto r2 =3D rx;` case), so =
we don&#39;t need this feature to cause the former.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>One nic=
e thing about P0352, that I might see a use for, is that it apparently re-e=
nables the ability to &quot;inherit from&quot; final classes. A few nifty m=
etaprogramming techniques went out the window with the introduction of the =
final qualifier, because you could no longer use the &quot;inherit from use=
r-defined T&quot; trick to get T&#39;s members into the same scope as some =
other member of your own devising. But with P0352, we can get all those mec=
hanisms back easily; final classes no longer have absolute power over libra=
ry writers.</div></div></blockquote><div><br>I don&#39;t think P0352 should=
 allow that. If a class is declared `final`, it seems decidedly poor form f=
or us to allow it to be used as a base class, even if it is not a base clas=
s subobject. I mean, you can decide that class-scoped `final` is a bad idea=
, but if we&#39;re going to have it, it should actually <i>work</i>.</div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dae5c070-c9f9-445e-915e-6189772622c4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dae5c070-c9f9-445e-915e-6189772622c4=
%40isocpp.org</a>.<br />

------=_Part_2644_661884124.1498606089229--

------=_Part_2643_1735758419.1498606089229--

.

--94eb2c06af40f4261b0552f9ed26
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On 27 June 2017 at 16:15, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

> On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wrote:
>>
>> On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <mathias...@gmail.com>
>> wrote:
>>
>>> A number of people on the committee seem to believe that adding
>>> complexity to the language is not a problem so long as that complexity =
is
>>> not exposed to the "everyday programmer". I think that's a terrible
>>> approach since any serious C++ developer, expert or not, needs to preci=
sely
>>> understand what the code they're looking at is doing.
>>>
>>
>> Yes, I also hate that kind of argument with a passion. It's just a
>> license to make inconsistent and confusing rules under the guise of bein=
g
>> "intuitive". Wanting simple or at the very least consistent rules is how=
 to
>> make the language easier to reason about.
>>
>
> Hear, hear.  I have not followed operator.() very closely because it
> generally does not matter to me, but I confess I found P0352R1 remarkably
> easy to grasp, and P0700 remarkably petty and whatever-the-word-is-for-no=
t-making-a-valid-point.
> Plus, on the technical merits, if typical *usage* of the feature doesn't
> involve the . character (but rather ++a and such other examples from the
> paper), I see no reason the feature should be defined with the syntax
> operator.. If the feature *acts* fundamentally like a user-defined
> type-conversion, I really really like the idea of *spelling* it like one.
>
> One thing that I did take from Stroustrup's P0700, though, is that I'm
> still confused about what the desired behavior is if I have
>
> template<class T> void f(T t);
> void g(Ref<X> r);
> Ref<X> rx;
> f(rx);  // deduce T=3DRef<X> or just X?
> g(rx);  // pass a copy of rx, or pass Ref<X>(X(rx))?
> auto r2 =3D rx;  // deduce Ref<X> or just X?
>
> I would *hope* that the desired behavior is "the former, not the latter"
> in each case, but that seems too... reasonable?  I mean, isn't the whole
> point of operator.() to create confusion about what is and what isn't a
> reference?
>
> One nice thing about P0352, that I might see a use for, is that it
> apparently re-enables the ability to "inherit from" final classes. A few
> nifty metaprogramming techniques went out the window with the introductio=
n
> of the final qualifier, because you could no longer use the "inherit from
> user-defined T" trick to get T's members into the same scope as some othe=
r
> member of your own devising. But with P0352, we can get all those
> mechanisms back easily; final classes no longer have absolute power over
> library writers.
>
> struct SpecialSnowflake final { };
>
> struct Ha_Ha : public using SpecialSnowflake {
>     SpecialSnowflake fake_base;
>     operator SpecialSnowflake& () { return fake_base; }
> };
>

One thing I really like about P0352 is that it gives us control over
virtual base classes. We don't have to accept the extra overhead that
compilers introduce for a fully general virtual base class implementation,
if (through knowledge of our own class hierarchy) we can do better.

=E2=80=93Arthur
>
> *C++:* You accidentally create a dozen instances of yourself and shoot
> them all in the foot. Providing emergency medical care is impossible sinc=
e
> you can't tell which are bitwise copies and which are just pointing at
> others and saying "that's me, over there."
>
> --
> 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/35d2f989-1938-4288-
> 89f4-114985039272%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/35d2f989-19=
38-4288-89f4-114985039272%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOfiQq%3D5pj3WV%3DMnAO1-92Q%2BH4-%3Dx8B53L%3Da-=
7C1JX7i9%3DJUQg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
7 June 2017 at 16:15, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wrote:<span c=
lass=3D""><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><di=
v class=3D"gmail_quote">On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <s=
pan dir=3D"ltr">&lt;<a rel=3D"nofollow">mathias...@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>A number o=
f people on the committee seem to believe that adding complexity to the lan=
guage is not a problem so long as that complexity is not exposed to the &qu=
ot;everyday programmer&quot;. I think that&#39;s a terrible approach since =
any serious C++ developer, expert or not, needs to precisely understand wha=
t the code they&#39;re looking at is doing.</div></div></blockquote><div><b=
r></div><div>Yes, I also hate that kind of argument with a passion. It&#39;=
s just a license to make inconsistent and confusing rules under the guise o=
f being &quot;intuitive&quot;. Wanting simple or at the very least consiste=
nt rules is how to make the language easier to reason about.</div></div></d=
iv></div></blockquote><div><br></div></span><div>Hear, hear.=C2=A0 I have n=
ot followed operator.() very closely because it generally does not matter t=
o me, but I confess I found P0352R1 remarkably easy to grasp, and P0700 rem=
arkably petty and whatever-the-word-is-for-not-<wbr>making-a-valid-point.=
=C2=A0 Plus, on the technical merits, if typical=C2=A0<i>usage</i> of the f=
eature doesn&#39;t involve the <font face=3D"courier new, monospace">.</fon=
t> character (but rather <font face=3D"courier new, monospace">++a</font> a=
nd such other examples from the paper), I see no reason the feature should =
be defined with the syntax <font face=3D"courier new, monospace">operator.<=
/font>. If the feature <i>acts</i> fundamentally like a user-defined type-c=
onversion, I really really like the idea of <i>spelling</i> it like one.</d=
iv><div><br></div><div>One thing that I did take from Stroustrup&#39;s P070=
0, though, is that I&#39;m still confused about what the desired behavior i=
s if I have</div><div><br></div><div><font face=3D"courier new, monospace">=
template&lt;class T&gt; void f(T t);</font></div><div><font face=3D"courier=
 new, monospace">void g(Ref&lt;X&gt; r);</font></div><div><font face=3D"cou=
rier new, monospace">Ref&lt;X&gt; rx;</font></div><div><font face=3D"courie=
r new, monospace">f(rx); =C2=A0// deduce T=3DRef&lt;X&gt; or just X?</font>=
</div><div><font face=3D"courier new, monospace">g(rx); =C2=A0// pass a cop=
y of rx, or pass Ref&lt;X&gt;(X(rx))?</font></div><div><font face=3D"courie=
r new, monospace">auto r2 =3D rx; =C2=A0// deduce Ref&lt;X&gt; or just X?</=
font></div><div><br></div><div>I would <i>hope</i> that the desired behavio=
r is &quot;the former, not the latter&quot; in each case, but that seems to=
o... reasonable?=C2=A0 I mean, isn&#39;t the whole point of operator.() to =
create confusion about what is and what isn&#39;t a reference?</div><div><b=
r></div><div>One nice thing about P0352, that I might see a use for, is tha=
t it apparently re-enables the ability to &quot;inherit from&quot; final cl=
asses. A few nifty metaprogramming techniques went out the window with the =
introduction of the final qualifier, because you could no longer use the &q=
uot;inherit from user-defined T&quot; trick to get T&#39;s members into the=
 same scope as some other member of your own devising. But with P0352, we c=
an get all those mechanisms back easily; final classes no longer have absol=
ute power over library writers.</div><div><br></div><div><font face=3D"cour=
ier new, monospace">struct SpecialSnowflake final { };</font></div><div><fo=
nt face=3D"courier new, monospace"><br></font></div><div><font face=3D"cour=
ier new, monospace">struct Ha_Ha : public using SpecialSnowflake {</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 SpecialSnowfla=
ke fake_base;</font></div><div><font face=3D"courier new, monospace">=C2=A0=
 =C2=A0 operator SpecialSnowflake&amp; () { return fake_base; }</font></div=
><div><font face=3D"courier new, monospace">};</font></div></div></blockquo=
te><div><br></div><div>One thing I really like about P0352 is that it gives=
 us control over virtual base classes. We don&#39;t have to accept the extr=
a overhead that compilers introduce for a fully general virtual base class =
implementation, if (through knowledge of our own class hierarchy) we can do=
 better.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>=E2=80=93Arthur</div><div><br></div><div><dl style=3D"color:rgb(0,0,=
0);font-family:Georgia,Garamond,Palatino,&#39;Times New Roman&#39;,times,se=
rif;font-size:16px;text-align:justify"><dd style=3D"max-width:36em"><b>C++:=
</b> You accidentally create a dozen instances of yourself and shoot them a=
ll in the foot. Providing emergency medical care is impossible since you ca=
n&#39;t tell which are bitwise copies and which are just pointing at others=
 and saying &quot;that&#39;s me, over there.&quot;</dd></dl></div></div><sp=
an class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/35d2f989-1938-4288-89f4-114985039272%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/35d2=
f989-1938-4288-<wbr>89f4-114985039272%40isocpp.org</a><wbr>.<br>
</blockquote></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D5pj3WV%3DMnAO1-92Q%2BH4-%3D=
x8B53L%3Da-7C1JX7i9%3DJUQg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAO=
fiQq%3D5pj3WV%3DMnAO1-92Q%2BH4-%3Dx8B53L%3Da-7C1JX7i9%3DJUQg%40mail.gmail.c=
om</a>.<br />

--94eb2c06af40f4261b0552f9ed26--

.

------=_Part_2505_1638352736.1498608330085
Content-Type: multipart/alternative;
 boundary="----=_Part_2506_537845090.1498608330086"

------=_Part_2506_537845090.1498608330086
Content-Type: text/plain; charset="UTF-8"

The point of P0352 is to not have to define any new rules. So all the
examples Stroustrup was confused about work as if Ref<T> actually inherited
T in the original sense.

This means "the former, not the latter" in each case, except if the
expresstion-template conversion-to-auto operator is in the Ref<X> API,
which may be appropriate for some kinds of references.

I'm unsure whether this should be viewed as inheritance-like enough to
disallow it for final classes. Initially I was inclined to agree with Nicol
but on the other hand it seems strange to not be able to create a Ref<T>
just because T is final. Noone would expect this to be forbidden and in the
alternate operator.() implementation it would definitely not be forbidden.
So I changed my mind and now think that Arthur should be allowed to create
a by-value member and refer to it.

One point I agree with Stroustrup about is a bit of unease with the need
for mentioning the refered type twice. Unfortunately my suggested syntax
has the same flaw, except if use auto as the return type of the refered
function:

template<typename T> class Ref : public T(get_ref) {
     T* m_ptr;
     auto get_ref() { return *m_ptr; }
};

So the syntax idea was to explicitly mention a named method in the
baseclass list instead of (re)using the using keyword yet again.

Semantically I see no difference, except possibly leaving the operator T&()
signature open for other uses, but this would be very confusing on the
other hand.

Initially I wanted to use a & on the base type to indicate "inheritance by
reference" but then I had no way to specify the function (or so I thought).
The use of a conversion operator seems like the right tool, I think maybe
that:

template<typename T> class Ref : public T& {
     operator T&() { ... }
};

could be more intuitive than the using keyword, but whatever syntax I have
a strong feeling that P0352 is the right way to go rather than operator.()
with any semantics. Lets help clarifying the paper in a new version with
more use cases to make it more convincing to all readers.



Den onsdag 28 juni 2017 kl. 01:28:09 UTC+2 skrev Nicol Bolas:
>
>
>
> On Tuesday, June 27, 2017 at 7:15:38 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wrote:
>>>
>>> On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <mathias...@gmail.com>
>>> wrote:
>>>
>>>> A number of people on the committee seem to believe that adding
>>>> complexity to the language is not a problem so long as that complexity is
>>>> not exposed to the "everyday programmer". I think that's a terrible
>>>> approach since any serious C++ developer, expert or not, needs to precisely
>>>> understand what the code they're looking at is doing.
>>>>
>>>
>>> Yes, I also hate that kind of argument with a passion. It's just a
>>> license to make inconsistent and confusing rules under the guise of being
>>> "intuitive". Wanting simple or at the very least consistent rules is how to
>>> make the language easier to reason about.
>>>
>>
>> Hear, hear.  I have not followed operator.() very closely because it
>> generally does not matter to me, but I confess I found P0352R1 remarkably
>> easy to grasp, and P0700 remarkably petty and
>> whatever-the-word-is-for-not-making-a-valid-point.  Plus, on the technical
>> merits, if typical *usage* of the feature doesn't involve the .
>> character (but rather ++a and such other examples from the paper), I see
>> no reason the feature should be defined with the syntax operator.. If
>> the feature *acts* fundamentally like a user-defined type-conversion, I
>> really really like the idea of *spelling* it like one.
>>
>> One thing that I did take from Stroustrup's P0700, though, is that I'm
>> still confused about what the desired behavior is if I have
>>
>> template<class T> void f(T t);
>> void g(Ref<X> r);
>> Ref<X> rx;
>> f(rx);  // deduce T=Ref<X> or just X?
>> g(rx);  // pass a copy of rx, or pass Ref<X>(X(rx))?
>> auto r2 = rx;  // deduce Ref<X> or just X?
>>
>> I would *hope* that the desired behavior is "the former, not the latter"
>> in each case, but that seems too... reasonable?  I mean, isn't the whole
>> point of operator.() to create confusion about what is and what isn't a
>> reference?
>>
>
> Well, the P0416 paper says "When  we  pass  a  smart  reference as  a
> template  argument  or  initialize  an auto
> object,  we  must  decide which type to deduce to: the handle or the
> value? We deduce to the handle."
>
> Also, we already have a paper to allow the latter <http://wg21.link/P0672>
> (at least, for the `auto r2 = rx;` case), so we don't need this feature to
> cause the former.
>
> One nice thing about P0352, that I might see a use for, is that it
>> apparently re-enables the ability to "inherit from" final classes. A few
>> nifty metaprogramming techniques went out the window with the introduction
>> of the final qualifier, because you could no longer use the "inherit from
>> user-defined T" trick to get T's members into the same scope as some other
>> member of your own devising. But with P0352, we can get all those
>> mechanisms back easily; final classes no longer have absolute power over
>> library writers.
>>
>
> I don't think P0352 should allow that. If a class is declared `final`, it
> seems decidedly poor form for us to allow it to be used as a base class,
> even if it is not a base class subobject. I mean, you can decide that
> class-scoped `final` is a bad idea, but if we're going to have it, it
> should actually *work*.
>

--
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/0d0d403b-020f-4134-91db-c997bcf2aabe%40isocpp.org.

------=_Part_2506_537845090.1498608330086
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The point of P0352 is to not have to define any new rules.=
 So all the examples Stroustrup was confused about work as if Ref&lt;T&gt; =
actually inherited T in the original sense.<div><br></div><div>This means &=
quot;the former, not the latter&quot; in each case, except if the expressti=
on-template conversion-to-auto operator is in the Ref&lt;X&gt; API, which m=
ay be appropriate for some kinds of references.</div><div><br></div><div>I&=
#39;m unsure whether this should be viewed as inheritance-like enough to di=
sallow it for final classes. Initially I was inclined to agree with Nicol b=
ut on the other hand it seems strange to not be able to create a Ref&lt;T&g=
t; just because T is final. Noone would expect this to be forbidden and in =
the alternate operator.() implementation it would definitely not be forbidd=
en. So I changed my mind and now think that Arthur should be allowed to cre=
ate a by-value member and refer to it.</div><div><br></div><div>One point I=
 agree with Stroustrup about is a bit of unease with the need for mentionin=
g the refered type twice. Unfortunately my suggested syntax has the same fl=
aw, except if use auto as the return type of the refered function:</div><di=
v><br></div><div>template&lt;typename T&gt; class Ref : public T(get_ref) {=
</div><div>=C2=A0 =C2=A0 =C2=A0T* m_ptr;</div><div>=C2=A0 =C2=A0 =C2=A0auto=
 get_ref() { return *m_ptr; }</div><div>};</div><div><br></div><div>So the =
syntax idea was to explicitly mention a named method in the baseclass list =
instead of (re)using the using keyword yet again.</div><div><br></div><div>=
Semantically I see no difference, except possibly leaving the operator T&am=
p;() signature open for other uses, but this would be very confusing on the=
 other hand.</div><div><br></div><div>Initially I wanted to use a &amp; on =
the base type to indicate &quot;inheritance by reference&quot; but then I h=
ad no way to specify the function (or so I thought). The use of a conversio=
n operator seems like the right tool, I think maybe that:</div><div><br></d=
iv><div>template&lt;typename T&gt; class Ref : public T&amp; {</div><div>=
=C2=A0 =C2=A0 =C2=A0operator T&amp;() { ... }</div><div>};</div><div><br></=
div><div>could be more intuitive than the using keyword, but whatever synta=
x I have a strong feeling that P0352 is the right way to go rather than ope=
rator.() with any semantics. Lets help clarifying the paper in a new versio=
n with more use cases to make it more convincing to all readers.</div><div>=
<div><br></div><div><br><br>Den onsdag 28 juni 2017 kl. 01:28:09 UTC+2 skre=
v Nicol Bolas:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><br><br>On Tuesday, June 27, 2017 at 7:15:38 PM UTC-4, Arthur O&#39;Dwyer =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, =
June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese 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"><div><div class=3D"gmail_quote">On =
Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">mathias...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"auto"><div>A number of people on the committee =
seem to believe that adding complexity to the language is not a problem so =
long as that complexity is not exposed to the &quot;everyday programmer&quo=
t;. I think that&#39;s a terrible approach since any serious C++ developer,=
 expert or not, needs to precisely understand what the code they&#39;re loo=
king at is doing.</div></div></blockquote><div><br></div><div>Yes, I also h=
ate that kind of argument with a passion. It&#39;s just a license to make i=
nconsistent and confusing rules under the guise of being &quot;intuitive&qu=
ot;. Wanting simple or at the very least consistent rules is how to make th=
e language easier to reason about.</div></div></div></div></blockquote><div=
><br></div><div>Hear, hear. =C2=A0I have not followed operator.() very clos=
ely because it generally does not matter to me, but I confess I found P0352=
R1 remarkably easy to grasp, and P0700 remarkably petty and whatever-the-wo=
rd-is-for-not-<wbr>making-a-valid-point. =C2=A0Plus, on the technical merit=
s, if typical=C2=A0<i>usage</i> of the feature doesn&#39;t involve the <fon=
t face=3D"courier new, monospace">.</font> character (but rather <font face=
=3D"courier new, monospace">++a</font> and such other examples from the pap=
er), I see no reason the feature should be defined with the syntax <font fa=
ce=3D"courier new, monospace">operator.</font>. If the feature <i>acts</i> =
fundamentally like a user-defined type-conversion, I really really like the=
 idea of <i>spelling</i> it like one.</div><div><br></div><div>One thing th=
at I did take from Stroustrup&#39;s P0700, though, is that I&#39;m still co=
nfused about what the desired behavior is if I have</div><div><br></div><di=
v><font face=3D"courier new, monospace">template&lt;class T&gt; void f(T t)=
;</font></div><div><font face=3D"courier new, monospace">void g(Ref&lt;X&gt=
; r);</font></div><div><font face=3D"courier new, monospace">Ref&lt;X&gt; r=
x;</font></div><div><font face=3D"courier new, monospace">f(rx); =C2=A0// d=
educe T=3DRef&lt;X&gt; or just X?</font></div><div><font face=3D"courier ne=
w, monospace">g(rx); =C2=A0// pass a copy of rx, or pass Ref&lt;X&gt;(X(rx)=
)?</font></div><div><font face=3D"courier new, monospace">auto r2 =3D rx; =
=C2=A0// deduce Ref&lt;X&gt; or just X?</font></div><div><br></div><div>I w=
ould <i>hope</i> that the desired behavior is &quot;the former, not the lat=
ter&quot; in each case, but that seems too... reasonable? =C2=A0I mean, isn=
&#39;t the whole point of operator.() to create confusion about what is and=
 what isn&#39;t a reference?</div></div></blockquote><div><br>Well, the P04=
16 paper says &quot;When=C2=A0 we=C2=A0 pass=C2=A0 a=C2=A0 smart=C2=A0 refe=
rence as=C2=A0 a=C2=A0 template=C2=A0 argument=C2=A0 or=C2=A0 initialize=C2=
=A0 an auto<br>object,=C2=A0 we=C2=A0 must=C2=A0 decide which type to deduc=
e to: the handle or the value? We deduce to the handle.&quot;<br><br>Also, =
we already have <a href=3D"http://wg21.link/P0672" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fwg21.link%2FP0672\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGCoEI=
QNzPBDopELkCdvQJAydjQrA&#39;;return true;" onclick=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0672\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNGCoEIQNzPBDopELkCdvQJAydjQrA&#39;;return true;">a pa=
per to allow the latter</a> (at least, for the `auto r2 =3D rx;` case), so =
we don&#39;t need this feature to cause the former.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>One nice thi=
ng about P0352, that I might see a use for, is that it apparently re-enable=
s the ability to &quot;inherit from&quot; final classes. A few nifty metapr=
ogramming techniques went out the window with the introduction of the final=
 qualifier, because you could no longer use the &quot;inherit from user-def=
ined T&quot; trick to get T&#39;s members into the same scope as some other=
 member of your own devising. But with P0352, we can get all those mechanis=
ms back easily; final classes no longer have absolute power over library wr=
iters.</div></div></blockquote><div><br>I don&#39;t think P0352 should allo=
w that. If a class is declared `final`, it seems decidedly poor form for us=
 to allow it to be used as a base class, even if it is not a base class sub=
object. I mean, you can decide that class-scoped `final` is a bad idea, but=
 if we&#39;re going to have it, it should actually <i>work</i>.</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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0d0d403b-020f-4134-91db-c997bcf2aabe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0d0d403b-020f-4134-91db-c997bcf2aabe=
%40isocpp.org</a>.<br />

------=_Part_2506_537845090.1498608330086--

------=_Part_2505_1638352736.1498608330085--

.

------=_Part_2681_786149403.1498608622084
Content-Type: multipart/alternative;
 boundary="----=_Part_2682_253414766.1498608622084"

------=_Part_2682_253414766.1498608622084
Content-Type: text/plain; charset="UTF-8"

Just one more thing: One approach to cover up the inconsistency created if
Ref<int> was allowed (which I think it must) would be to actually allow
inheritance (yes, normal inheritance) from builtin types. I was expecting
to easily find an example that shows why this is impossible, but I could
not come up with any... so tell me why!


Den onsdag 28 juni 2017 kl. 02:05:30 UTC+2 skrev Bengt Gustafsson:
>
> The point of P0352 is to not have to define any new rules. So all the
> examples Stroustrup was confused about work as if Ref<T> actually inherited
> T in the original sense.
>
> This means "the former, not the latter" in each case, except if the
> expresstion-template conversion-to-auto operator is in the Ref<X> API,
> which may be appropriate for some kinds of references.
>
> I'm unsure whether this should be viewed as inheritance-like enough to
> disallow it for final classes. Initially I was inclined to agree with Nicol
> but on the other hand it seems strange to not be able to create a Ref<T>
> just because T is final. Noone would expect this to be forbidden and in the
> alternate operator.() implementation it would definitely not be forbidden.
> So I changed my mind and now think that Arthur should be allowed to create
> a by-value member and refer to it.
>
> One point I agree with Stroustrup about is a bit of unease with the need
> for mentioning the refered type twice. Unfortunately my suggested syntax
> has the same flaw, except if use auto as the return type of the refered
> function:
>
> template<typename T> class Ref : public T(get_ref) {
>      T* m_ptr;
>      auto get_ref() { return *m_ptr; }
> };
>
> So the syntax idea was to explicitly mention a named method in the
> baseclass list instead of (re)using the using keyword yet again.
>
> Semantically I see no difference, except possibly leaving the operator
> T&() signature open for other uses, but this would be very confusing on the
> other hand.
>
> Initially I wanted to use a & on the base type to indicate "inheritance by
> reference" but then I had no way to specify the function (or so I thought).
> The use of a conversion operator seems like the right tool, I think maybe
> that:
>
> template<typename T> class Ref : public T& {
>      operator T&() { ... }
> };
>
> could be more intuitive than the using keyword, but whatever syntax I have
> a strong feeling that P0352 is the right way to go rather than operator.()
> with any semantics. Lets help clarifying the paper in a new version with
> more use cases to make it more convincing to all readers.
>
>
>
> Den onsdag 28 juni 2017 kl. 01:28:09 UTC+2 skrev Nicol Bolas:
>>
>>
>>
>> On Tuesday, June 27, 2017 at 7:15:38 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wrote:
>>>>
>>>> On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <mathias...@gmail.com>
>>>> wrote:
>>>>
>>>>> A number of people on the committee seem to believe that adding
>>>>> complexity to the language is not a problem so long as that complexity is
>>>>> not exposed to the "everyday programmer". I think that's a terrible
>>>>> approach since any serious C++ developer, expert or not, needs to precisely
>>>>> understand what the code they're looking at is doing.
>>>>>
>>>>
>>>> Yes, I also hate that kind of argument with a passion. It's just a
>>>> license to make inconsistent and confusing rules under the guise of being
>>>> "intuitive". Wanting simple or at the very least consistent rules is how to
>>>> make the language easier to reason about.
>>>>
>>>
>>> Hear, hear.  I have not followed operator.() very closely because it
>>> generally does not matter to me, but I confess I found P0352R1 remarkably
>>> easy to grasp, and P0700 remarkably petty and
>>> whatever-the-word-is-for-not-making-a-valid-point.  Plus, on the technical
>>> merits, if typical *usage* of the feature doesn't involve the .
>>> character (but rather ++a and such other examples from the paper), I
>>> see no reason the feature should be defined with the syntax operator..
>>> If the feature *acts* fundamentally like a user-defined
>>> type-conversion, I really really like the idea of *spelling* it like
>>> one.
>>>
>>> One thing that I did take from Stroustrup's P0700, though, is that I'm
>>> still confused about what the desired behavior is if I have
>>>
>>> template<class T> void f(T t);
>>> void g(Ref<X> r);
>>> Ref<X> rx;
>>> f(rx);  // deduce T=Ref<X> or just X?
>>> g(rx);  // pass a copy of rx, or pass Ref<X>(X(rx))?
>>> auto r2 = rx;  // deduce Ref<X> or just X?
>>>
>>> I would *hope* that the desired behavior is "the former, not the
>>> latter" in each case, but that seems too... reasonable?  I mean, isn't the
>>> whole point of operator.() to create confusion about what is and what isn't
>>> a reference?
>>>
>>
>> Well, the P0416 paper says "When  we  pass  a  smart  reference as  a
>> template  argument  or  initialize  an auto
>> object,  we  must  decide which type to deduce to: the handle or the
>> value? We deduce to the handle."
>>
>> Also, we already have a paper to allow the latter
>> <http://wg21.link/P0672> (at least, for the `auto r2 = rx;` case), so we
>> don't need this feature to cause the former.
>>
>> One nice thing about P0352, that I might see a use for, is that it
>>> apparently re-enables the ability to "inherit from" final classes. A few
>>> nifty metaprogramming techniques went out the window with the introduction
>>> of the final qualifier, because you could no longer use the "inherit from
>>> user-defined T" trick to get T's members into the same scope as some other
>>> member of your own devising. But with P0352, we can get all those
>>> mechanisms back easily; final classes no longer have absolute power over
>>> library writers.
>>>
>>
>> I don't think P0352 should allow that. If a class is declared `final`, it
>> seems decidedly poor form for us to allow it to be used as a base class,
>> even if it is not a base class subobject. I mean, you can decide that
>> class-scoped `final` is a bad idea, but if we're going to have it, it
>> should actually *work*.
>>
>

--
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/893351fd-7b11-4a69-975f-e1e50e605089%40isocpp.org.

------=_Part_2682_253414766.1498608622084
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Just one more thing: One approach to cover up the inconsis=
tency created if Ref&lt;int&gt; was allowed (which I think it must) would b=
e to actually allow inheritance (yes, normal inheritance) from builtin type=
s. I was expecting to easily find an example that shows why this is impossi=
ble, but I could not come up with any... so tell me why!<div><br><br>Den on=
sdag 28 juni 2017 kl. 02:05:30 UTC+2 skrev Bengt Gustafsson:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr">The point of P0352 is to not=
 have to define any new rules. So all the examples Stroustrup was confused =
about work as if Ref&lt;T&gt; actually inherited T in the original sense.<d=
iv><br></div><div>This means &quot;the former, not the latter&quot; in each=
 case, except if the expresstion-template conversion-to-auto operator is in=
 the Ref&lt;X&gt; API, which may be appropriate for some kinds of reference=
s.</div><div><br></div><div>I&#39;m unsure whether this should be viewed as=
 inheritance-like enough to disallow it for final classes. Initially I was =
inclined to agree with Nicol but on the other hand it seems strange to not =
be able to create a Ref&lt;T&gt; just because T is final. Noone would expec=
t this to be forbidden and in the alternate operator.() implementation it w=
ould definitely not be forbidden. So I changed my mind and now think that A=
rthur should be allowed to create a by-value member and refer to it.</div><=
div><br></div><div>One point I agree with Stroustrup about is a bit of unea=
se with the need for mentioning the refered type twice. Unfortunately my su=
ggested syntax has the same flaw, except if use auto as the return type of =
the refered function:</div><div><br></div><div>template&lt;typename T&gt; c=
lass Ref : public T(get_ref) {</div><div>=C2=A0 =C2=A0 =C2=A0T* m_ptr;</div=
><div>=C2=A0 =C2=A0 =C2=A0auto get_ref() { return *m_ptr; }</div><div>};</d=
iv><div><br></div><div>So the syntax idea was to explicitly mention a named=
 method in the baseclass list instead of (re)using the using keyword yet ag=
ain.</div><div><br></div><div>Semantically I see no difference, except poss=
ibly leaving the operator T&amp;() signature open for other uses, but this =
would be very confusing on the other hand.</div><div><br></div><div>Initial=
ly I wanted to use a &amp; on the base type to indicate &quot;inheritance b=
y reference&quot; but then I had no way to specify the function (or so I th=
ought). The use of a conversion operator seems like the right tool, I think=
 maybe that:</div><div><br></div><div>template&lt;typename T&gt; class Ref =
: public T&amp; {</div><div>=C2=A0 =C2=A0 =C2=A0operator T&amp;() { ... }</=
div><div>};</div><div><br></div><div>could be more intuitive than the using=
 keyword, but whatever syntax I have a strong feeling that P0352 is the rig=
ht way to go rather than operator.() with any semantics. Lets help clarifyi=
ng the paper in a new version with more use cases to make it more convincin=
g to all readers.</div><div><div><br></div><div><br><br>Den onsdag 28 juni =
2017 kl. 01:28:09 UTC+2 skrev Nicol Bolas:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><br><br>On Tuesday, June 27, 2017 at 7:15:38 PM UTC=
-4, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">On Tuesday, June 27, 2017 at 1:41:13 PM UTC-7, Matt Calabrese wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote">On Tue, Jun 27, 2017 at 3:44 PM, Mathias Gaunard <span di=
r=3D"ltr">&lt;<a rel=3D"nofollow">mathias...@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>A number of peop=
le on the committee seem to believe that adding complexity to the language =
is not a problem so long as that complexity is not exposed to the &quot;eve=
ryday programmer&quot;. I think that&#39;s a terrible approach since any se=
rious C++ developer, expert or not, needs to precisely understand what the =
code they&#39;re looking at is doing.</div></div></blockquote><div><br></di=
v><div>Yes, I also hate that kind of argument with a passion. It&#39;s just=
 a license to make inconsistent and confusing rules under the guise of bein=
g &quot;intuitive&quot;. Wanting simple or at the very least consistent rul=
es is how to make the language easier to reason about.</div></div></div></d=
iv></blockquote><div><br></div><div>Hear, hear. =C2=A0I have not followed o=
perator.() very closely because it generally does not matter to me, but I c=
onfess I found P0352R1 remarkably easy to grasp, and P0700 remarkably petty=
 and whatever-the-word-is-for-not-<wbr>making-a-valid-point. =C2=A0Plus, on=
 the technical merits, if typical=C2=A0<i>usage</i> of the feature doesn&#3=
9;t involve the <font face=3D"courier new, monospace">.</font> character (b=
ut rather <font face=3D"courier new, monospace">++a</font> and such other e=
xamples from the paper), I see no reason the feature should be defined with=
 the syntax <font face=3D"courier new, monospace">operator.</font>. If the =
feature <i>acts</i> fundamentally like a user-defined type-conversion, I re=
ally really like the idea of <i>spelling</i> it like one.</div><div><br></d=
iv><div>One thing that I did take from Stroustrup&#39;s P0700, though, is t=
hat I&#39;m still confused about what the desired behavior is if I have</di=
v><div><br></div><div><font face=3D"courier new, monospace">template&lt;cla=
ss T&gt; void f(T t);</font></div><div><font face=3D"courier new, monospace=
">void g(Ref&lt;X&gt; r);</font></div><div><font face=3D"courier new, monos=
pace">Ref&lt;X&gt; rx;</font></div><div><font face=3D"courier new, monospac=
e">f(rx); =C2=A0// deduce T=3DRef&lt;X&gt; or just X?</font></div><div><fon=
t face=3D"courier new, monospace">g(rx); =C2=A0// pass a copy of rx, or pas=
s Ref&lt;X&gt;(X(rx))?</font></div><div><font face=3D"courier new, monospac=
e">auto r2 =3D rx; =C2=A0// deduce Ref&lt;X&gt; or just X?</font></div><div=
><br></div><div>I would <i>hope</i> that the desired behavior is &quot;the =
former, not the latter&quot; in each case, but that seems too... reasonable=
? =C2=A0I mean, isn&#39;t the whole point of operator.() to create confusio=
n about what is and what isn&#39;t a reference?</div></div></blockquote><di=
v><br>Well, the P0416 paper says &quot;When=C2=A0 we=C2=A0 pass=C2=A0 a=C2=
=A0 smart=C2=A0 reference as=C2=A0 a=C2=A0 template=C2=A0 argument=C2=A0 or=
=C2=A0 initialize=C2=A0 an auto<br>object,=C2=A0 we=C2=A0 must=C2=A0 decide=
 which type to deduce to: the handle or the value? We deduce to the handle.=
&quot;<br><br>Also, we already have <a href=3D"http://wg21.link/P0672" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0672\x26sa\x3dD\x26sntz\x3d1\=
x26usg\x3dAFQjCNGCoEIQNzPBDopELkCdvQJAydjQrA&#39;;return true;" onclick=3D"=
this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwg21.link%2FP0=
672\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGCoEIQNzPBDopELkCdvQJAydjQrA&#3=
9;;return true;">a paper to allow the latter</a> (at least, for the `auto r=
2 =3D rx;` case), so we don&#39;t need this feature to cause the former.<br=
><br></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><div>One nice thing about P0352, that I might see a use for, is that it=
 apparently re-enables the ability to &quot;inherit from&quot; final classe=
s. A few nifty metaprogramming techniques went out the window with the intr=
oduction of the final qualifier, because you could no longer use the &quot;=
inherit from user-defined T&quot; trick to get T&#39;s members into the sam=
e scope as some other member of your own devising. But with P0352, we can g=
et all those mechanisms back easily; final classes no longer have absolute =
power over library writers.</div></div></blockquote><div><br>I don&#39;t th=
ink P0352 should allow that. If a class is declared `final`, it seems decid=
edly poor form for us to allow it to be used as a base class, even if it is=
 not a base class subobject. I mean, you can decide that class-scoped `fina=
l` is a bad idea, but if we&#39;re going to have it, it should actually <i>=
work</i>.</div></div></blockquote></div></div></div></blockquote></div></di=
v>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/893351fd-7b11-4a69-975f-e1e50e605089%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/893351fd-7b11-4a69-975f-e1e50e605089=
%40isocpp.org</a>.<br />

------=_Part_2682_253414766.1498608622084--

------=_Part_2681_786149403.1498608622084--

.

--089e082246ac98847c0552fc199f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 27, 2017 at 5:05 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:

> The point of P0352 is to not have to define any new rules. So all the
> examples Stroustrup was confused about work as if Ref<T> actually inherit=
ed
> T in the original sense.
>
> This means "the former, not the latter" in each case, except if the
> expresstion-template conversion-to-auto operator is in the Ref<X> API,
> which may be appropriate for some kinds of references.
>

FWIW, I think I'm vaguely aware of "operator auto", but I don't understand
what expression templates have to do with it.

[...]

> One point I agree with Stroustrup about is a bit of unease with the need
> for mentioning the refered type twice. Unfortunately my suggested syntax
> has the same flaw, except if use auto as the return type of the refered
> function:
>
> template<typename T> class Ref : public T(get_ref) {
>      T* m_ptr;
>      auto get_ref() { return *m_ptr; }
> };
>
> So the syntax idea was to explicitly mention a named method in the
> baseclass list instead of (re)using the using keyword yet again.
>

Even without "auto", this has the same problem w.r.t. the repetition of the
word "get_ref". Also, I don't instantly intuitively understand what should
happen if "get_ref" is an inherited member, or if I inherit from Ref<T> and
override "get_ref" =E2=80=94 I suspect it all falls out naturally but for s=
ome
reason "operator T&" doesn't cause that mental block for me.
One benefit of the "get_ref" approach is that "get_ref" could be a static
member function, whereas I suppose "operator T&" cannot be static.
Another benefit of the "get_ref" approach is that if we re-use "operator
T&" for purposes of operator.(), then we're unnecessarily tying together
the notions of "delegates-all-the-members-of-T-like-so" and
"is-implicitly-convertible-to-T". I can easily imagine a "smart reference"
type that doesn't want to be implicitly (nor explicitly) convertible to T&,
just as I can easily imagine a "smart pointer" type that doesn't want to be
implicitly (nor explicitly) convertible to T*.



> Semantically I see no difference, except possibly leaving the operator
> T&() signature open for other uses, but this would be very confusing on t=
he
> other hand.
>

The "operator T&" signature already has a meaning =E2=80=94 implicit/explic=
it
conversion to T& =E2=80=94 which is why I'm suddenly a bit less keen on it.=
 The
idea of pulling names into scope via something-like-inheritance is still
correct IMO, but I don't like tying the actual process of *delegation* to
the result of a specific *conversion* operator.



> Initially I wanted to use a & on the base type to indicate "inheritance b=
y
> reference" but then I had no way to specify the function (or so I thought=
).
> The use of a conversion operator seems like the right tool, I think maybe
> that:
>
> template<typename T> class Ref : public T& {
>      operator T&() { ... }
> };
>

Here you'd have to make a really convincing argument that "inherit from T&"
shouldn't have some other meaning. I think you and I would probably agree
that "inherit from int" has a reasonably intuitive meaning, and "inherit
from pointer-to-int" has a reasonably intuitive meaning; but do our
intuitions diverge at "inherit from reference-to-int"?  Don't answer that.
;)

Here's another addition to the syntax bikeshed:

template<typename T> class Ref {
private:
    T *p;
public:
    public T&() { return *p; }
    public const T&() const { return *p; }
};

The advantage of this syntax (without anything explicitly in the class
header) is that you can have const and non-const versions that give
different results; for example, giving back an iterator in one case and a
const_iterator in another. I have no use-cases in mind.
The "public" here is meant to indicate that it works kind of like public
inheritance; however, I have no idea what "private" would mean in the same
context, given that the access control of the function is actually
controlled by the "public:" on the preceding line. P0352R1 has the exact
same problem: it's unclear what would happen if you wrote

template<typename T> class Ref : public using T {
private:
    T *p;
    operator T&() { return *p; }  // this is a private conversion operator!
};

(Does this Ref<T> behave like a smart reference only in friend contexts?)

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0%2BAWkB9U1%3D_GqQ_Wz2A%3D18sfrB%2B5o%2BX1=
pww1CvXkFt%2B%2Bg%40mail.gmail.com.

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

<div dir=3D"ltr">On Tue, Jun 27, 2017 at 5:05 PM, Bengt Gustafsson <span di=
r=3D"ltr">&lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_b=
lank">bengt.gustafsson@beamways.com</a>&gt;</span> wrote:<br><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">T=
he point of P0352 is to not have to define any new rules. So all the exampl=
es Stroustrup was confused about work as if Ref&lt;T&gt; actually inherited=
 T in the original sense.<div><br></div><div>This means &quot;the former, n=
ot the latter&quot; in each case, except if the expresstion-template conver=
sion-to-auto operator is in the Ref&lt;X&gt; API, which may be appropriate =
for some kinds of references.</div></div></blockquote><div><br></div><div>F=
WIW, I think I&#39;m vaguely aware of &quot;operator auto&quot;, but I don&=
#39;t understand what expression templates have to do with it.</div><div><b=
r></div><div>[...]</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div>One point I =
agree with Stroustrup about is a bit of unease with the need for mentioning=
 the refered type twice. Unfortunately my suggested syntax has the same fla=
w, except if use auto as the return type of the refered function:<br></div>=
<div><br></div><div>template&lt;typename T&gt; class Ref : public T(get_ref=
) {</div><div>=C2=A0 =C2=A0 =C2=A0T* m_ptr;</div><div>=C2=A0 =C2=A0 =C2=A0a=
uto get_ref() { return *m_ptr; }</div><div>};</div><div><br></div><div>So t=
he syntax idea was to explicitly mention a named method in the baseclass li=
st instead of (re)using the using keyword yet again.</div></div></blockquot=
e><div><br></div><div>Even without &quot;auto&quot;, this has the same prob=
lem w.r.t. the repetition of the word &quot;get_ref&quot;. Also, I don&#39;=
t instantly intuitively understand what should happen if &quot;get_ref&quot=
; is an inherited member, or if I inherit from Ref&lt;T&gt; and override &q=
uot;get_ref&quot; =E2=80=94 I suspect it all falls out naturally but for so=
me reason &quot;operator T&amp;&quot; doesn&#39;t cause that mental block f=
or me.</div><div>One benefit of the &quot;get_ref&quot; approach is that &q=
uot;get_ref&quot; could be a static member function, whereas I suppose &quo=
t;operator T&amp;&quot; cannot be static.</div><div>Another benefit of the =
&quot;get_ref&quot; approach is that if we re-use &quot;operator T&amp;&quo=
t; for purposes of operator.(), then we&#39;re unnecessarily tying together=
 the notions of &quot;delegates-all-the-members-of-T-like-so&quot; and &quo=
t;is-implicitly-convertible-to-T&quot;. I can easily imagine a &quot;smart =
reference&quot; type that doesn&#39;t want to be implicitly (nor explicitly=
) convertible to T&amp;, just as I can easily imagine a &quot;smart pointer=
&quot; type that doesn&#39;t want to be implicitly (nor explicitly) convert=
ible to T*.</div><div><br></div><div>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div =
dir=3D"ltr"><div>Semantically I see no difference, except possibly leaving =
the operator T&amp;() signature open for other uses, but this would be very=
 confusing on the other hand.<br></div></div></blockquote><div><br></div><d=
iv>The &quot;operator T&amp;&quot; signature already has a meaning =E2=80=
=94 implicit/explicit conversion to T&amp; =E2=80=94 which is why I&#39;m s=
uddenly a bit less keen on it. The idea of pulling names into scope via som=
ething-like-inheritance is still correct IMO, but I don&#39;t like tying th=
e actual process of=C2=A0<i>delegation</i> to the result of a specific <i>c=
onversion</i> operator.</div><div><br></div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr"><div></div><div>Initially I wanted to use a &amp; on th=
e base type to indicate &quot;inheritance by reference&quot; but then I had=
 no way to specify the function (or so I thought). The use of a conversion =
operator seems like the right tool, I think maybe that:<br></div><div><br><=
/div><div>template&lt;typename T&gt; class Ref : public T&amp; {</div><div>=
=C2=A0 =C2=A0 =C2=A0operator T&amp;() { ... }</div><div>};</div></div></blo=
ckquote><div><br></div><div>Here you&#39;d have to make a really convincing=
 argument that &quot;inherit from T&amp;&quot; shouldn&#39;t have some othe=
r meaning. I think you and I would probably agree that &quot;inherit from i=
nt&quot; has a reasonably intuitive meaning, and &quot;inherit from pointer=
-to-int&quot; has a reasonably intuitive meaning; but do our intuitions div=
erge at &quot;inherit from reference-to-int&quot;?=C2=A0 Don&#39;t answer t=
hat. ;)</div><div><br></div><div>Here&#39;s another addition to the syntax =
bikeshed:</div><div><br></div><div>template&lt;typename T&gt; class Ref {</=
div><div>private:</div><div>=C2=A0 =C2=A0 T *p;</div><div>public:</div><div=
>=C2=A0 =C2=A0 public T&amp;() { return *p; }</div><div>=C2=A0 =C2=A0 publi=
c const T&amp;() const { return *p; }</div><div>};</div><div><br></div><div=
>The advantage of this syntax (without anything explicitly in the class hea=
der) is that you can have const and non-const versions that give different =
results; for example, giving back an iterator in one case and a const_itera=
tor in another. I have no use-cases in mind.</div><div>The &quot;public&quo=
t; here is meant to indicate that it works kind of like public inheritance;=
 however, I have no idea what &quot;private&quot; would mean in the same co=
ntext, given that the access control of the function is actually controlled=
 by the &quot;public:&quot; on the preceding line. P0352R1 has the exact sa=
me problem: it&#39;s unclear what would happen if you wrote</div><div><br><=
/div><div>template&lt;typename T&gt; class Ref : public using T {</div><div=
>private:</div><div>=C2=A0 =C2=A0 T *p;</div><div>=C2=A0 =C2=A0 operator T&=
amp;() { return *p; } =C2=A0// this is a private conversion operator!</div>=
<div>};</div><div><br></div><div>(Does this Ref&lt;T&gt; behave like a smar=
t reference only in friend contexts?)</div><div><br></div><div>=E2=80=93Art=
hur</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0%2BAWkB9U1%3D_GqQ_Wz2A%3D18sfr=
B%2B5o%2BX1pww1CvXkFt%2B%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAD=
vuK0%2BAWkB9U1%3D_GqQ_Wz2A%3D18sfrB%2B5o%2BX1pww1CvXkFt%2B%2Bg%40mail.gmail=
..com</a>.<br />

--089e082246ac98847c0552fc199f--

.

------=_Part_2737_1470004813.1498643102602
Content-Type: multipart/alternative;
 boundary="----=_Part_2738_1872629144.1498643102603"

------=_Part_2738_1872629144.1498643102603
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Den onsdag 28 juni 2017 kl. 04:40:00 UTC+2 skrev Arthur O'Dwyer:
>
> On Tue, Jun 27, 2017 at 5:05 PM, Bengt Gustafsson <
> bengt.gu...@beamways.com <javascript:>> wrote:
>
>> The point of P0352 is to not have to define any new rules. So all the=20
>> examples Stroustrup was confused about work as if Ref<T> actually inheri=
ted=20
>> T in the original sense.
>>
>> This means "the former, not the latter" in each case, except if the=20
>> expresstion-template conversion-to-auto operator is in the Ref<X> API,=
=20
>> which may be appropriate for some kinds of references.
>>
>
> FWIW, I think I'm vaguely aware of "operator auto", but I don't understan=
d=20
> what expression templates have to do with it.
>
operator auto (at least the meaning I put into that notion) is a way to=20
define a type that an object of the type having the operator will be=20
converted to in case it is assigned to an auto variable.
The primary use case is for expression templates where you typically would=
=20
like to evaluate the expression when assigning it to an auto variable:

auto m =3D A * B;

If A and B are matrices in a library with lazy evaluation you would expect=
=20
m to be a matrix, not some obscure type in the expression template motor.


=20

>
> [...]
>
>> One point I agree with Stroustrup about is a bit of unease with the need=
=20
>> for mentioning the refered type twice. Unfortunately my suggested syntax=
=20
>> has the same flaw, except if use auto as the return type of the refered=
=20
>> function:
>>
>> template<typename T> class Ref : public T(get_ref) {
>>      T* m_ptr;
>>      auto get_ref() { return *m_ptr; }
>> };
>>
>> So the syntax idea was to explicitly mention a named method in the=20
>> baseclass list instead of (re)using the using keyword yet again.
>>
>
> Even without "auto", this has the same problem w.r.t. the repetition of=
=20
> the word "get_ref". Also, I don't instantly intuitively understand what=
=20
> should happen if "get_ref" is an inherited member, or if I inherit from=
=20
> Ref<T> and override "get_ref" =E2=80=94 I suspect it all falls out natura=
lly but=20
> for some reason "operator T&" doesn't cause that mental block for me.
>
I guess the usual lookup rules would apply, which would crate the=20
possibility to actually refer to a method of the reffered object, which=20
would not work out very well. So this is a drawback (unless conversion=20
operators are inherited, which I don't remember if they are).
=20

> One benefit of the "get_ref" approach is that "get_ref" could be a static=
=20
> member function, whereas I suppose "operator T&" cannot be static.
>
I don't know if there is a rule to prevent static conversion operators.
=20

> Another benefit of the "get_ref" approach is that if we re-use "operator=
=20
> T&" for purposes of operator.(), then we're unnecessarily tying together=
=20
> the notions of "delegates-all-the-members-of-T-like-so" and=20
> "is-implicitly-convertible-to-T". I can easily imagine a "smart reference=
"=20
> type that doesn't want to be implicitly (nor explicitly) convertible to T=
&,=20
> just as I can easily imagine a "smart pointer" type that doesn't want to =
be=20
> implicitly (nor explicitly) convertible to T*.
>
Yes, but then maybe we could encode that by making the conversion operator=
=20
private, with the view that when refering to the "base class" we do that as=
=20
member of the class. Well, maybe not totally logical but it would be=20
possible to define it that way.
=20

>
> =20
>
>> Semantically I see no difference, except possibly leaving the operator=
=20
>> T&() signature open for other uses, but this would be very confusing on =
the=20
>> other hand.
>>
>
> The "operator T&" signature already has a meaning =E2=80=94 implicit/expl=
icit=20
> conversion to T& =E2=80=94 which is why I'm suddenly a bit less keen on i=
t. The=20
> idea of pulling names into scope via something-like-inheritance is still=
=20
> correct IMO, but I don't like tying the actual process of *delegation* to=
=20
> the result of a specific *conversion* operator.
>
Yes, I think we share a similar vague uneasiness about this then.

=20

>
> =20
>
>> Initially I wanted to use a & on the base type to indicate "inheritance=
=20
>> by reference" but then I had no way to specify the function (or so I=20
>> thought). The use of a conversion operator seems like the right tool, I=
=20
>> think maybe that:
>>
>> template<typename T> class Ref : public T& {
>>      operator T&() { ... }
>> };
>>
>
> Here you'd have to make a really convincing argument that "inherit from=
=20
> T&" shouldn't have some other meaning. I think you and I would probably=
=20
> agree that "inherit from int" has a reasonably intuitive meaning, and=20
> "inherit from pointer-to-int" has a reasonably intuitive meaning; but do=
=20
> our intuitions diverge at "inherit from reference-to-int"?  Don't answer=
=20
> that. ;)
>
> Here's another addition to the syntax bikeshed:
>
> template<typename T> class Ref {
> private:
>     T *p;
> public:
>     public T&() { return *p; }
>     public const T&() const { return *p; }
> };
>
> The advantage of this syntax (without anything explicitly in the class=20
> header) is that you can have const and non-const versions that give=20
> different results; for example, giving back an iterator in one case and a=
=20
> const_iterator in another. I have no use-cases in mind.
>
I think this would be confusing to anyone having programmed in java or C#.=
=20
I would intuitively interpret it as a way to make an exception to the=20
general rule in this part of the class head (like defining one public=20
method in the private: section). I guess there may be some who think=20
harmonizing with other languages and thus allow this would be a good idea.

I notice that you dropped the 'operator' keyword which makes it a bit odd.=
=20
This could be a good thing as it stands out more.

I also had the idea to explore how this idea could be expressed without=20
using the base class list. My take was to add a context sensitive keyword=
=20
allowed after a conversion operator, which makes it more "powerful",=20
defined as "behaves as if it inherited T":

    template<typename T> class Ref<T> {
    public:
        operator T&() implicit { return *m_ptr; }
    };

The choice of the word implicit is motivated by the fact that it can=20
loosely be seen as the inverse of 'explicit' on a conversion operator. When=
=20
explicit makes it harder to call (accidentally) implicit makes it easier,=
=20
again: As if it was inheriting T. We could also select the word 'inherit'=
=20
to make it perfectly clear how to interpret the result.

When pursuing this line of thought I started thinking about what the actual=
=20
difference between inheritance and (non explicit) conversion operator to a=
=20
reference is. After all both convert a reference to Ref<T> to a reference=
=20
to T. There are two differences I could think of: 1) The cost of the=20
conversion operator is higher, so that the compiler only does one of them.=
=20
2) the baseclass conversion is done for the "this" pointer when accessing=
=20
members,which is not done for a conversion operator. I don't think there=20
would be a difference for a template function parameter, in both cases=20
Ref<T> would be chosen as no conversions are done.=20

With concepts in the picture I guess this could change: Imagine a class A=
=20
which has an operator B() and a template function with a concept C as=20
parameter type. B fulfills the C concept but A doesn't.Would this function=
=20
be callable with an A as it has a conversion operator to a type fulfilling=
=20
a concept? My spontaneous feeling is that it should not, but for=20
inheritance by reference in any form it would be  allowed as presumably a=
=20
subclass fulfills all concepts that its baseclass fulfills (given public=20
inheritance of course).

=20

> The "public" here is meant to indicate that it works kind of like public=
=20
> inheritance; however, I have no idea what "private" would mean in the sam=
e=20
> context, given that the access control of the function is actually=20
> controlled by the "public:" on the preceding line. P0352R1 has the exact=
=20
> same problem: it's unclear what would happen if you wrote
>
> template<typename T> class Ref : public using T {
> private:
>     T *p;
>     operator T&() { return *p; }  // this is a private conversion operato=
r!
> };
>
> (Does this Ref<T> behave like a smart reference only in friend contexts?)
>
Or, as I described above, it could mean to only be usable for the "convert=
=20
to baseclass" idiom, but not being callable directly. However, given the=20
intermediate discussion: I don't see how a conversion operator would ever=
=20
be called "directly" as the compiler would always find the=20
convert-to-baseclass path easier when it today would find the conversion=20
operator. Well you could do:
   =20
    Ref<int> x;
    x.operator int();

and then it would complain that it was private, but basically it seems that=
=20
the public/private on the inheritance and the public/private on the=20
conversion operator are redundant, which speaks for a solution without=20
mentioning in the base class list as it would require extra rules for what=
=20
happens if the public/private of the two places are not the same.

=20

>
> =E2=80=93Arthur
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/901f5c75-086a-4f86-97d8-ee64975ace78%40isocpp.or=
g.

------=_Part_2738_1872629144.1498643102603
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Den onsdag 28 juni 2017 kl. 04:40:00 UTC+2 skrev A=
rthur O&#39;Dwyer:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Tue, Jun 27, 2017 at 5:05 PM, Bengt Gustafsson <span dir=3D"ltr">&l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Y2a27H=
ASAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">ben=
gt.gu...@beamways.com</a><wbr>&gt;</span> wrote:<br><div><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr">The point of P0352 is to not hav=
e to define any new rules. So all the examples Stroustrup was confused abou=
t work as if Ref&lt;T&gt; actually inherited T in the original sense.<div><=
br></div><div>This means &quot;the former, not the latter&quot; in each cas=
e, except if the expresstion-template conversion-to-auto operator is in the=
 Ref&lt;X&gt; API, which may be appropriate for some kinds of references.</=
div></div></blockquote><div><br></div><div>FWIW, I think I&#39;m vaguely aw=
are of &quot;operator auto&quot;, but I don&#39;t understand what expressio=
n templates have to do with it.</div></div></div></div></blockquote><div>op=
erator auto (at least the meaning I put into that notion) is a way to defin=
e a type that an object of the type having the operator will be converted t=
o in case it is assigned to an auto variable.</div><div>The primary use cas=
e is for expression templates where you typically would like to evaluate th=
e expression when assigning it to an auto variable:</div><div><br></div><di=
v>auto m =3D A * B;</div><div><br></div><div>If A and B are matrices in a l=
ibrary with lazy evaluation you would expect m to be a matrix, not some obs=
cure type in the expression template motor.</div><div><br></div><div><br></=
div><div>=C2=A0<br></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 class=3D"gmail_quote"><div><br></div><div>[...]</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>One point I agree with Stroustrup ab=
out is a bit of unease with the need for mentioning the refered type twice.=
 Unfortunately my suggested syntax has the same flaw, except if use auto as=
 the return type of the refered function:<br></div><div><br></div><div>temp=
late&lt;typename T&gt; class Ref : public T(get_ref) {</div><div>=C2=A0 =C2=
=A0 =C2=A0T* m_ptr;</div><div>=C2=A0 =C2=A0 =C2=A0auto get_ref() { return *=
m_ptr; }</div><div>};</div><div><br></div><div>So the syntax idea was to ex=
plicitly mention a named method in the baseclass list instead of (re)using =
the using keyword yet again.</div></div></blockquote><div><br></div><div>Ev=
en without &quot;auto&quot;, this has the same problem w.r.t. the repetitio=
n of the word &quot;get_ref&quot;. Also, I don&#39;t instantly intuitively =
understand what should happen if &quot;get_ref&quot; is an inherited member=
, or if I inherit from Ref&lt;T&gt; and override &quot;get_ref&quot; =E2=80=
=94 I suspect it all falls out naturally but for some reason &quot;operator=
 T&amp;&quot; doesn&#39;t cause that mental block for me.</div></div></div>=
</div></blockquote><div>I guess the usual lookup rules would apply, which w=
ould crate the possibility to actually refer to a method of the reffered ob=
ject, which would not work out very well. So this is a drawback (unless con=
version operators are inherited, which I don&#39;t remember if they are).</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>One benefit of the &quot;get_=
ref&quot; approach is that &quot;get_ref&quot; could be a static member fun=
ction, whereas I suppose &quot;operator T&amp;&quot; cannot be static.</div=
></div></div></div></blockquote><div>I don&#39;t know if there is a rule to=
 prevent static conversion operators.</div><div>=C2=A0</div><blockquote cla=
ss=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 class=3D"gmail_quo=
te"><div>Another benefit of the &quot;get_ref&quot; approach is that if we =
re-use &quot;operator T&amp;&quot; for purposes of operator.(), then we&#39=
;re unnecessarily tying together the notions of &quot;delegates-all-the-mem=
bers-of-<wbr>T-like-so&quot; and &quot;is-implicitly-convertible-to-<wbr>T&=
quot;. I can easily imagine a &quot;smart reference&quot; type that doesn&#=
39;t want to be implicitly (nor explicitly) convertible to T&amp;, just as =
I can easily imagine a &quot;smart pointer&quot; type that doesn&#39;t want=
 to be implicitly (nor explicitly) convertible to T*.</div></div></div></di=
v></blockquote><div>Yes, but then maybe we could encode that by making the =
conversion operator private, with the view that when refering to the &quot;=
base class&quot; we do that as member of the class. Well, maybe not totally=
 logical but it would be possible to define it that way.</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=
 class=3D"gmail_quote"><div><br></div><div>=C2=A0<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><div dir=3D"ltr"><div>Semantically I see no difference, except possibly le=
aving the operator T&amp;() signature open for other uses, but this would b=
e very confusing on the other hand.<br></div></div></blockquote><div><br></=
div><div>The &quot;operator T&amp;&quot; signature already has a meaning =
=E2=80=94 implicit/explicit conversion to T&amp; =E2=80=94 which is why I&#=
39;m suddenly a bit less keen on it. The idea of pulling names into scope v=
ia something-like-inheritance is still correct IMO, but I don&#39;t like ty=
ing the actual process of=C2=A0<i>delegation</i> to the result of a specifi=
c <i>conversion</i> operator.</div></div></div></div></blockquote><div>Yes,=
 I think we share a similar vague uneasiness about this then.</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 d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div></div><div>Initially I wanted to use=
 a &amp; on the base type to indicate &quot;inheritance by reference&quot; =
but then I had no way to specify the function (or so I thought). The use of=
 a conversion operator seems like the right tool, I think maybe that:<br></=
div><div><br></div><div>template&lt;typename T&gt; class Ref : public T&amp=
; {</div><div>=C2=A0 =C2=A0 =C2=A0operator T&amp;() { ... }</div><div>};</d=
iv></div></blockquote><div><br></div><div>Here you&#39;d have to make a rea=
lly convincing argument that &quot;inherit from T&amp;&quot; shouldn&#39;t =
have some other meaning. I think you and I would probably agree that &quot;=
inherit from int&quot; has a reasonably intuitive meaning, and &quot;inheri=
t from pointer-to-int&quot; has a reasonably intuitive meaning; but do our =
intuitions diverge at &quot;inherit from reference-to-int&quot;?=C2=A0 Don&=
#39;t answer that. ;)</div><div><br></div><div>Here&#39;s another addition =
to the syntax bikeshed:</div><div><br></div><div>template&lt;typename T&gt;=
 class Ref {</div><div>private:</div><div>=C2=A0 =C2=A0 T *p;</div><div>pub=
lic:</div><div>=C2=A0 =C2=A0 public T&amp;() { return *p; }</div><div>=C2=
=A0 =C2=A0 public const T&amp;() const { return *p; }</div><div>};</div><di=
v><br></div><div>The advantage of this syntax (without anything explicitly =
in the class header) is that you can have const and non-const versions that=
 give different results; for example, giving back an iterator in one case a=
nd a const_iterator in another. I have no use-cases in mind.</div></div></d=
iv></div></blockquote><div>I think this would be confusing to anyone having=
 programmed in java or C#. I would intuitively interpret it as a way to mak=
e an exception to the general rule in this part of the class head (like def=
ining one public method in the private: section). I guess there may be some=
 who think harmonizing with other languages and thus allow this would be a =
good idea.</div><div><br></div><div>I notice that you dropped the &#39;oper=
ator&#39; keyword which makes it a bit odd. This could be a good thing as i=
t stands out more.</div><div><br></div><div>I also had the idea to explore =
how this idea could be expressed without using the base class list. My take=
 was to add a context sensitive keyword allowed after a conversion operator=
, which makes it more &quot;powerful&quot;, defined as &quot;behaves as if =
it inherited T&quot;:</div><div><br></div><div>=C2=A0 =C2=A0 template&lt;ty=
pename T&gt; class Ref&lt;T&gt; {</div><div>=C2=A0 =C2=A0 public:</div><div=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 operator T&amp;() implicit { return *m_ptr; }<=
/div><div>=C2=A0 =C2=A0 };</div><div><br></div><div>The choice of the word =
implicit is motivated by the fact that it can loosely be seen as the invers=
e of &#39;explicit&#39; on a conversion operator. When explicit makes it ha=
rder to call (accidentally) implicit makes it easier, again: As if it was i=
nheriting T. We could also select the word &#39;inherit&#39; to make it per=
fectly clear how to interpret the result.</div><div><br></div><div>When pur=
suing this line of thought I started thinking about what the actual differe=
nce between inheritance and (non explicit) conversion operator to a referen=
ce is. After all both convert a reference to Ref&lt;T&gt; to a reference to=
 T. There are two differences I could think of: 1) The cost of the conversi=
on operator is higher, so that the compiler only does one of them. 2) the b=
aseclass conversion is done for the &quot;this&quot; pointer when accessing=
 members,which is not done for a conversion operator. I don&#39;t think the=
re would be a difference for a template function parameter, in both cases R=
ef&lt;T&gt; would be chosen as no conversions are done.=C2=A0</div><div><br=
></div><div>With concepts in the picture I guess this could change: Imagine=
 a class A which has an operator B() and a template function with a concept=
 C as parameter type. B fulfills the C concept but A doesn&#39;t.Would this=
 function be callable with an A as it has a conversion operator to a type f=
ulfilling a concept? My spontaneous feeling is that it should not, but for =
inheritance by reference in any form it would be =C2=A0allowed as presumabl=
y a subclass fulfills all concepts that its baseclass fulfills (given publi=
c inheritance of course).</div><div><br></div><div>=C2=A0<br></div><blockqu=
ote 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 class=3D"gm=
ail_quote"><div>The &quot;public&quot; here is meant to indicate that it wo=
rks kind of like public inheritance; however, I have no idea what &quot;pri=
vate&quot; would mean in the same context, given that the access control of=
 the function is actually controlled by the &quot;public:&quot; on the prec=
eding line. P0352R1 has the exact same problem: it&#39;s unclear what would=
 happen if you wrote</div><div><br></div><div>template&lt;typename T&gt; cl=
ass Ref : public using T {</div><div>private:</div><div>=C2=A0 =C2=A0 T *p;=
</div><div>=C2=A0 =C2=A0 operator T&amp;() { return *p; } =C2=A0// this is =
a private conversion operator!</div><div>};</div><div><br></div><div>(Does =
this Ref&lt;T&gt; behave like a smart reference only in friend contexts?)</=
div></div></div></div></blockquote><div>Or, as I described above, it could =
mean to only be usable for the &quot;convert to baseclass&quot; idiom, but =
not being callable directly. However, given the intermediate discussion: I =
don&#39;t see how a conversion operator would ever be called &quot;directly=
&quot; as the compiler would always find the convert-to-baseclass path easi=
er when it today would find the conversion operator. Well you could do:</di=
v><div>=C2=A0 =C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 Ref&lt;int&gt; x;</div><=
div>=C2=A0 =C2=A0 x.operator int();</div><div><br></div><div>and then it wo=
uld complain that it was private, but basically it seems that the public/pr=
ivate on the inheritance and the public/private on the conversion operator =
are redundant, which speaks for a solution without mentioning in the base c=
lass list as it would require extra rules for what happens if the public/pr=
ivate of the two places are not the same.</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=
 class=3D"gmail_quote"><div><br></div><div>=E2=80=93Arthur</div></div></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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/901f5c75-086a-4f86-97d8-ee64975ace78%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/901f5c75-086a-4f86-97d8-ee64975ace78=
%40isocpp.org</a>.<br />

------=_Part_2738_1872629144.1498643102603--

------=_Part_2737_1470004813.1498643102602--

.

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

On 28 June 2017 at 10:45, Bengt Gustafsson <bengt.gustafsson@beamways.com>
wrote:

>
> operator auto (at least the meaning I put into that notion) is a way to
> define a type that an object of the type having the operator will be
> converted to in case it is assigned to an auto variable.
>


> The primary use case is for expression templates where you typically would
> like to evaluate the expression when assigning it to an auto variable:
>
> auto m = A * B;
>

As a big writer and user of expression templates libraries, I'm not sure
you really want that.
In any case, the simplest way to do this IMO would be to just allow users
to specialize std::decay, and to define auto in terms of it, but that's
another topic...

--
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/CALnjya8UuUaBufUw_3a2Dg%2BpW%3DNgp9qekXTC-uvOJtc2bZT3Gg%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
8 June 2017 at 10:45, Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsson@beamw=
ays.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><br><div>operator auto (at least the meaning I put into that notion) =
is a way to define a type that an object of the type having the operator wi=
ll be converted to in case it is assigned to an auto variable.</div></div><=
/blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>The primary use case is for expression templates where you typically=
 would like to evaluate the expression when assigning it to an auto variabl=
e:</div><div><br></div><div>auto m =3D A * B;</div></div></blockquote><div>=
<br>As a big writer and user of expression templates libraries, I&#39;m not=
 sure you really want that.</div><div>In any case, the simplest way to do t=
his IMO would be to just allow users to specialize std::decay, and to defin=
e auto in terms of it, but that&#39;s another topic...</div></div></div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALnjya8UuUaBufUw_3a2Dg%2BpW%3DNgp9qe=
kXTC-uvOJtc2bZT3Gg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALnjya8UuUaB=
ufUw_3a2Dg%2BpW%3DNgp9qekXTC-uvOJtc2bZT3Gg%40mail.gmail.com</a>.<br />

--94eb2c0b8eee4997f705530290ef--

.

On 2017-06-27 12:32, Nicol Bolas wrote:
> Stroustrup's P0700 (PDF) <http://wg21.link/P0700> paper is a critique of P0352:
> Smart References through Delegation (PDF) <http://wg21.link/P0352>.

(General observations)

If `operator.` *only* ever worked when an actual `.` appeared, I'd have
a somewhat harder time arguing against it. As much as it rubs me wrong
on an intuitive level, it *does* make *some* sense to compare it to
`operator->`. After all, the latter is also built-in for some types and
user defined for others.

Where this breaks down, however, is that I don't believe `->` is ever
defaulted for a user type. Either a type has built-in `->`, or it has
user-provided (or at worst, base-class-provided) `->`.

But then you throw in stuff like `++x` is supposed to call
`operator.`... wait, wtf?? What about `foo(x)`? Suddenly we are bending
Principle of Least Surprise into a pretzel.

Comparitively, P0352 leverages implicit conversions, so some of the
operations we want come from a feature that already exists. The rest
fall out from a slight tweaking of inheritence... the "proxy" is in
effect a subclass for lookup rules (something we have already), only the
implicit conversion when calling a "base class" member uses the provided
conversion operator rather than a built-in conversion (subclass to base
class). In fact, given that virtual inheritance can already have a
non-trivial form of this conversion, this isn't such a huge leap.

Oh, and... what about:

  ... Ref<X>::mem_fun(...)
  {
    foo(...); // Does this call Ref::foo or X::foo?
  }

Historically, whether to write `this->` in front of member access has
been a matter of style. With P0352, it is "obvious" that it remains
guaranteed safe (i.e. will not change meaning) to remove `this->`. Is
that still the case with P0416?

That all said, TBH I have never felt the need for the feature either of
these proposals would permit...

> With P0416, operator-dot, I now have to remember a bunch of new lookup
> rules. I have to check to see if a type overloads operator-dot. If it does,
> then I have to know exactly what the new rules are, that the proxied type
> takes priority. But these rules are complicated. There are times when the
> proxied type doesn't take priority (if I recall correctly, in constructors
> and destructors).  And more importantly, if I really want to access the
> proxy rather than the proxied type, I have to learn a complex new idiom:
> `std::addressof(x)->y`.
>
> The advantage of P0352 is that I *don't* have new rules to learn. `x.y`
> follows C++ lookup rules that have existed since the day C++ was
> standardized. The derived class overrides the base class names. That's the
> rule, and we all know it by heart. So the proxy takes priority. And if you
> want to ensure access to proxied members, we already have an idiom for
> that: `x.ProxiedType::y`. That's all well understood C++, and requires no
> extension to the rules to achieve.

Hear, hear.

On 2017-06-27 19:15, Arthur O'Dwyer wrote:
> One thing that I did take from Stroustrup's P0700, though, is that I'm
> still confused about what the desired behavior is if I have
>
> template<class T> void f(T t);
> void g(Ref<X> r);
> Ref<X> rx;
> f(rx);  // deduce T=Ref<X> or just X?
> g(rx);  // pass a copy of rx, or pass Ref<X>(X(rx))?
> auto r2 = rx;  // deduce Ref<X> or just X?
>
> I would *hope* that the desired behavior is "the former, not the latter" in
> each case, but that seems too... reasonable?  I mean, isn't the whole point
> of operator.() to create confusion about what is and what isn't a reference?

....and a nice aspect of P0352 is that it has *no effect* on any of the
above code. All of these behaviors would be controlled by the existence
of the implicit conversion operator, which is a feature we already have
today. Or, rather, they *wouldn't* be, because right now we get the
former behaviors, with or without the conversion operator being present
in `Ref`.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6b6205c-d22c-5430-8263-df34b15a7567%40gmail.com.

.

On 2017-06-27 19:28, Nicol Bolas wrote:
>> One nice thing about P0352, that I might see a use for, is that it=20
>> apparently re-enables the ability to "inherit from" final classes. A few=
=20
>> nifty metaprogramming techniques went out the window with the introducti=
on=20
>> of the final qualifier, because you could no longer use the "inherit fro=
m=20
>> user-defined T" trick to get T's members into the same scope as some oth=
er=20
>> member of your own devising. But with P0352, we can get all those=20
>> mechanisms back easily; final classes no longer have absolute power over=
=20
>> library writers.
>=20
> I don't think P0352 should allow that. If a class is declared `final`, it=
=20
> seems decidedly poor form for us to allow it to be used as a base class,=
=20
> even if it is not a base class subobject. I mean, you can decide that=20
> class-scoped `final` is a bad idea, but if we're going to have it, it=20
> should actually *work*.

If that were the case, it would be a *compelling* argument against
P0352. You can't very well have a "smart reference" / "proxy" type if
there is a mechanism to arbitrarily prevent it being used with some types.

That said... what is the use case for "final"? Maybe it's the Free
Software coder in me, but the idea of preventing someone extending your
class just rubs me wrong.

What's that? "Performance reasons", you say? Okay, I can buy that... but
therein lies the cool part; *allowing P0352 on `final` types should not
obviate the performance benefits of `final`*. Eat cake=C2=B9. Have cake.

(=C2=B9 The cake is not a lie ;-).)

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c2273655-cf87-c163-ab0b-f401915e5d7b%40gmail.com=
..

.

On 2017-06-27 22:39, Arthur O'Dwyer wrote:
> Here's another addition to the syntax bikeshed:
> [...]

If we're going to bikeshed, what about:

  template <typename X> class Ref {
    X* m_p;
    ...
  public:
    using X::* -> { return *m_p; }
  }

This says 'inherit all members of `X` as if it were a base class, and
when calling such a member, execute this code to obtain the reference to
`X`. The exact syntax is subject to further bikeshedding, but the
general idea is that there exists a public `using` declaration *in the
class body* which has the "conversion operator" code attached to it.

This could even be bolted on to P0352 as it currently stands:

  template <typename X> class Ref : public using X {
    X* m_p;
    ...
  public:
    using X -> { return *m_p; }
  }

Here, the `using X ->` syntax must be associated with `using X` as a
"base class". The latter provides a "conversion operator" that is *only*
accessible when performing a conversion due to P0352 name lookup.

An alternative syntax for this "limited use conversion operator" could
be e.g. `operator using X&() { ... }`.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/358d61fc-6c46-9d01-fada-f293df38b308%40gmail.com.

.

------=_Part_2713_2093129240.1498656606778
Content-Type: multipart/alternative;
 boundary="----=_Part_2714_670961778.1498656606778"

------=_Part_2714_670961778.1498656606778
Content-Type: text/plain; charset="UTF-8"



On Wednesday, June 28, 2017 at 7:50:12 AM UTC-4, Matthew Woehlke wrote:
>
> On 2017-06-27 19:28, Nicol Bolas wrote:
> >> One nice thing about P0352, that I might see a use for, is that it
> >> apparently re-enables the ability to "inherit from" final classes. A
> few
> >> nifty metaprogramming techniques went out the window with the
> introduction
> >> of the final qualifier, because you could no longer use the "inherit
> from
> >> user-defined T" trick to get T's members into the same scope as some
> other
> >> member of your own devising. But with P0352, we can get all those
> >> mechanisms back easily; final classes no longer have absolute power
> over
> >> library writers.
> >
> > I don't think P0352 should allow that. If a class is declared `final`,
> it
> > seems decidedly poor form for us to allow it to be used as a base class,
> > even if it is not a base class subobject. I mean, you can decide that
> > class-scoped `final` is a bad idea, but if we're going to have it, it
> > should actually *work*.
>
> If that were the case, it would be a *compelling* argument against
> P0352. You can't very well have a "smart reference" / "proxy" type if
> there is a mechanism to arbitrarily prevent it being used with some types.
>

Or we could just rip class-level `final` out of the language. I'm good with
that. C++ is just not a language where class `final` makes sense; we use
inheritance a lot for things that have nothing to do with traditional
vtable polymorphism.

That said... what is the use case for "final"? Maybe it's the Free
> Software coder in me, but the idea of preventing someone extending your
> class just rubs me wrong.
>
> What's that? "Performance reasons", you say?


The only performance benefit you could get is allowing the compiler to
de-virtualize virtual functions on the type. And you could get the same
effect by just saying that class-level `final` means that all virtual
functions, inherited or not, are implicitly declared `final`.

--
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/2eeebb85-9e57-47c8-a1d6-028c39e2803a%40isocpp.org.

------=_Part_2714_670961778.1498656606778
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, June 28, 2017 at 7:50:12 AM UTC-4, M=
atthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-0=
6-27 19:28, Nicol Bolas wrote:
<br>&gt;&gt; One nice thing about P0352, that I might see a use for, is tha=
t it=20
<br>&gt;&gt; apparently re-enables the ability to &quot;inherit from&quot; =
final classes. A few=20
<br>&gt;&gt; nifty metaprogramming techniques went out the window with the =
introduction=20
<br>&gt;&gt; of the final qualifier, because you could no longer use the &q=
uot;inherit from=20
<br>&gt;&gt; user-defined T&quot; trick to get T&#39;s members into the sam=
e scope as some other=20
<br>&gt;&gt; member of your own devising. But with P0352, we can get all th=
ose=20
<br>&gt;&gt; mechanisms back easily; final classes no longer have absolute =
power over=20
<br>&gt;&gt; library writers.
<br>&gt;=20
<br>&gt; I don&#39;t think P0352 should allow that. If a class is declared =
`final`, it=20
<br>&gt; seems decidedly poor form for us to allow it to be used as a base =
class,=20
<br>&gt; even if it is not a base class subobject. I mean, you can decide t=
hat=20
<br>&gt; class-scoped `final` is a bad idea, but if we&#39;re going to have=
 it, it=20
<br>&gt; should actually *work*.
<br>
<br>If that were the case, it would be a *compelling* argument against
<br>P0352. You can&#39;t very well have a &quot;smart reference&quot; / &qu=
ot;proxy&quot; type if
<br>there is a mechanism to arbitrarily prevent it being used with some typ=
es.
<br></blockquote><div><br>Or we could just rip class-level `final` out of t=
he language. I&#39;m good with that. C++ is just not a language where class=
 `final` makes sense; we use inheritance a lot for things that have nothing=
 to do with traditional vtable polymorphism.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">
That said... what is the use case for &quot;final&quot;? Maybe it&#39;s the=
 Free
<br>Software coder in me, but the idea of preventing someone extending your
<br>class just rubs me wrong.
<br>
<br>What&#39;s that? &quot;Performance reasons&quot;, you say?</blockquote>=
<div><br>The only performance benefit you could get is allowing the compile=
r to de-virtualize virtual functions on the type. And you could get the sam=
e effect by just saying that class-level `final` means that all virtual fun=
ctions, inherited or not, are implicitly declared `final`.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2eeebb85-9e57-47c8-a1d6-028c39e2803a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2eeebb85-9e57-47c8-a1d6-028c39e2803a=
%40isocpp.org</a>.<br />

------=_Part_2714_670961778.1498656606778--

------=_Part_2713_2093129240.1498656606778--

.

------=_Part_2727_1159408484.1498657225487
Content-Type: multipart/alternative;
 boundary="----=_Part_2728_1095735801.1498657225488"

------=_Part_2728_1095735801.1498657225488
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Tuesday, June 27, 2017 at 10:40:00 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Tue, Jun 27, 2017 at 5:05 PM, Bengt Gustafsson <
> bengt.gu...@beamways.com <javascript:>> wrote:
>
>> The point of P0352 is to not have to define any new rules. So all the=20
>> examples Stroustrup was confused about work as if Ref<T> actually inheri=
ted=20
>> T in the original sense.
>>
>> This means "the former, not the latter" in each case, except if the=20
>> expresstion-template conversion-to-auto operator is in the Ref<X> API,=
=20
>> which may be appropriate for some kinds of references.
>>
>
> FWIW, I think I'm vaguely aware of "operator auto", but I don't understan=
d=20
> what expression templates have to do with it.
>
> [...]
>
>> One point I agree with Stroustrup about is a bit of unease with the need=
=20
>> for mentioning the refered type twice. Unfortunately my suggested syntax=
=20
>> has the same flaw, except if use auto as the return type of the refered=
=20
>> function:
>>
>> template<typename T> class Ref : public T(get_ref) {
>>      T* m_ptr;
>>      auto get_ref() { return *m_ptr; }
>> };
>>
>> So the syntax idea was to explicitly mention a named method in the=20
>> baseclass list instead of (re)using the using keyword yet again.
>>
>
> Even without "auto", this has the same problem w.r.t. the repetition of=
=20
> the word "get_ref". Also, I don't instantly intuitively understand what=
=20
> should happen if "get_ref" is an inherited member, or if I inherit from=
=20
> Ref<T> and override "get_ref" =E2=80=94 I suspect it all falls out natura=
lly but=20
> for some reason "operator T&" doesn't cause that mental block for me.
>

The problem I have with trying to use a function other than `operator T&`=
=20
to convert to the delegated "base class" is that it now makes it possible=
=20
for people to create incoherence in their types. You provide some named=20
delegate function to do the conversion, but you could also provide an=20
implicit conversion to the same `T` which does a *different thing* than the=
=20
delegate.

I don't want to have to guess how this works:

T &t =3D variable;

I don't want to have to wonder if the `variable` object is calling the=20
delegate function or `operator T&`. I want to be able to see that it has an=
=20
`operator T&` and be reasonably assured that is what it is calling.
=20

> One benefit of the "get_ref" approach is that "get_ref" could be a static=
=20
> member function, whereas I suppose "operator T&" cannot be static.
>

Well, we could always change that. Granted, I'm not sure why you'd want=20
that.
=20

> Another benefit of the "get_ref" approach is that if we re-use "operator=
=20
> T&" for purposes of operator.(), then we're unnecessarily tying together=
=20
> the notions of "delegates-all-the-members-of-T-like-so" and=20
> "is-implicitly-convertible-to-T". I can easily imagine a "smart reference=
"=20
> type that doesn't want to be implicitly (nor explicitly) convertible to T=
&,=20
> just as I can easily imagine a "smart pointer" type that doesn't want to =
be=20
> implicitly (nor explicitly) convertible to T*.
>

I can't imagine that.

`weak_ptr` is the only "smart pointer" type I know that is not convertible=
=20
to `T*`. But, `weak_ptr` also doesn't have `operator->` overloaded; you=20
access the pointer through an entirely different API from most smart=20
pointers (and for good reason).

So what kind of smart pointer type would you be talking about where=20
`operator->` exists but not `operator T*`? I just don't think it makes=20
sense to be able to do `ptr->MemberOfT` and not be able to do `T* pt =3D pt=
r;=20
pt->MemberOfT;`.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/8731c7b6-90c3-4a63-9f0b-f284daa425eb%40isocpp.or=
g.

------=_Part_2728_1095735801.1498657225488
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, June 27, 2017 at 10:40:00 PM UTC-4, Ar=
thur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">On Tue, Jun 27, 2017 at 5:05 PM, Bengt Gustafsson <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Y=
2a27HASAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">bengt.gu...@beamways.com</a><wbr>&gt;</span> wrote:<br><div><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr">The point of P0352 is to no=
t have to define any new rules. So all the examples Stroustrup was confused=
 about work as if Ref&lt;T&gt; actually inherited T in the original sense.<=
div><br></div><div>This means &quot;the former, not the latter&quot; in eac=
h case, except if the expresstion-template conversion-to-auto operator is i=
n the Ref&lt;X&gt; API, which may be appropriate for some kinds of referenc=
es.</div></div></blockquote><div><br></div><div>FWIW, I think I&#39;m vague=
ly aware of &quot;operator auto&quot;, but I don&#39;t understand what expr=
ession templates have to do with it.</div><div><br></div><div>[...]</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>One point I agree with Stroustrup abou=
t is a bit of unease with the need for mentioning the refered type twice. U=
nfortunately my suggested syntax has the same flaw, except if use auto as t=
he return type of the refered function:<br></div><div><br></div><div>templa=
te&lt;typename T&gt; class Ref : public T(get_ref) {</div><div>=C2=A0 =C2=
=A0 =C2=A0T* m_ptr;</div><div>=C2=A0 =C2=A0 =C2=A0auto get_ref() { return *=
m_ptr; }</div><div>};</div><div><br></div><div>So the syntax idea was to ex=
plicitly mention a named method in the baseclass list instead of (re)using =
the using keyword yet again.</div></div></blockquote><div><br></div><div>Ev=
en without &quot;auto&quot;, this has the same problem w.r.t. the repetitio=
n of the word &quot;get_ref&quot;. Also, I don&#39;t instantly intuitively =
understand what should happen if &quot;get_ref&quot; is an inherited member=
, or if I inherit from Ref&lt;T&gt; and override &quot;get_ref&quot; =E2=80=
=94 I suspect it all falls out naturally but for some reason &quot;operator=
 T&amp;&quot; doesn&#39;t cause that mental block for me.</div></div></div>=
</div></blockquote><div><br>The problem I have with trying to use a functio=
n other than `operator T&amp;` to convert to the delegated &quot;base class=
&quot; is that it now makes it possible for people to create incoherence in=
 their types. You provide some named delegate function to do the conversion=
, but you could also provide an implicit conversion to the same `T` which d=
oes a <i>different thing</i> than the delegate.<br><br>I don&#39;t want to =
have to guess how this works:<br><br><div style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">T </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">t </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> variable</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span></div></code></div><br>I don&#39;t want to have to wonder if the=
 `variable` object is calling the delegate function or `operator T&amp;`. I=
 want to be able to see that it has an `operator T&amp;` and be reasonably =
assured that is what it is calling.<br>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=
One benefit of the &quot;get_ref&quot; approach is that &quot;get_ref&quot;=
 could be a static member function, whereas I suppose &quot;operator T&amp;=
&quot; cannot be static.</div></div></div></div></blockquote><div><br>Well,=
 we could always change that. Granted, I&#39;m not sure why you&#39;d want =
that.<br>=C2=A0</div><div></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 class=3D"gmail_quote"><div>Another benefit of =
the &quot;get_ref&quot; approach is that if we re-use &quot;operator T&amp;=
&quot; for purposes of operator.(), then we&#39;re unnecessarily tying toge=
ther the notions of &quot;delegates-all-the-members-of-<wbr>T-like-so&quot;=
 and &quot;is-implicitly-convertible-to-<wbr>T&quot;. I can easily imagine =
a &quot;smart reference&quot; type that doesn&#39;t want to be implicitly (=
nor explicitly) convertible to T&amp;, just as I can easily imagine a &quot=
;smart pointer&quot; type that doesn&#39;t want to be implicitly (nor expli=
citly) convertible to T*.</div></div></div></div></blockquote><div><br>I ca=
n&#39;t imagine that.<br><br>`weak_ptr` is the only &quot;smart pointer&quo=
t; type I know that is not convertible to `T*`. But, `weak_ptr` also doesn&=
#39;t have `operator-&gt;` overloaded; you access the pointer through an en=
tirely different API from most smart pointers (and for good reason).<br><br=
>So what kind of smart pointer type would you be talking about where `opera=
tor-&gt;` exists but not `operator T*`? I just don&#39;t think it makes sen=
se to be able to do `ptr-&gt;MemberOfT` and not be able to do `T* pt =3D pt=
r; pt-&gt;MemberOfT;`.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8731c7b6-90c3-4a63-9f0b-f284daa425eb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8731c7b6-90c3-4a63-9f0b-f284daa425eb=
%40isocpp.org</a>.<br />

------=_Part_2728_1095735801.1498657225488--

------=_Part_2727_1159408484.1498657225487--

.

------=_Part_2979_910321078.1498659797899
Content-Type: multipart/alternative;
 boundary="----=_Part_2980_1159733254.1498659797899"

------=_Part_2980_1159733254.1498659797899
Content-Type: text/plain; charset="UTF-8"


>
>
> So what kind of smart pointer type would you be talking about where
> `operator->` exists but not `operator T*`? I just don't think it makes
> sense to be able to do `ptr->MemberOfT` and not be able to do `T* pt = ptr;
> pt->MemberOfT;`.
>

Maybe I'm misunderstanding, but neither std::unique_ptr<T> nor
std::shared_ptr<T> have an operator T*.

--
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/f80fbb9b-a795-4645-839f-d92f7f8d9238%40isocpp.org.

------=_Part_2980_1159733254.1498659797899
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><br>So what kind of smart pointer type would you be talking about =
where `operator-&gt;` exists but not `operator T*`? I just don&#39;t think =
it makes sense to be able to do `ptr-&gt;MemberOfT` and not be able to do `=
T* pt =3D ptr; pt-&gt;MemberOfT;`.</div></div></blockquote><div><br></div><=
div>Maybe I&#39;m misunderstanding, but neither std::unique_ptr&lt;T&gt; no=
r std::shared_ptr&lt;T&gt; have an operator T*. =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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f80fbb9b-a795-4645-839f-d92f7f8d9238%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f80fbb9b-a795-4645-839f-d92f7f8d9238=
%40isocpp.org</a>.<br />

------=_Part_2980_1159733254.1498659797899--

------=_Part_2979_910321078.1498659797899--

.

------=_Part_1460_407900685.1498660377525
Content-Type: multipart/alternative;
 boundary="----=_Part_1461_1535317294.1498660377525"

------=_Part_1461_1535317294.1498660377525
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 10:23:18 AM UTC-4, Barry Revzin wrote:
>
>
>> So what kind of smart pointer type would you be talking about where
>> `operator->` exists but not `operator T*`? I just don't think it makes
>> sense to be able to do `ptr->MemberOfT` and not be able to do `T* pt = ptr;
>> pt->MemberOfT;`.
>>
>
> Maybe I'm misunderstanding, but neither std::unique_ptr<T> nor
> std::shared_ptr<T> have an operator T*.
>

I could have sworn they had implicit conversions to T*. I guess I've gotten
so used to writing `.get()` that I don't even notice it...

--
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/3acb523d-cc8a-4942-8166-d80533bfd53b%40isocpp.org.

------=_Part_1461_1535317294.1498660377525
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 10:23:18 AM UTC-4, Barry Re=
vzin 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"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>So what kin=
d of smart pointer type would you be talking about where `operator-&gt;` ex=
ists but not `operator T*`? I just don&#39;t think it makes sense to be abl=
e to do `ptr-&gt;MemberOfT` and not be able to do `T* pt =3D ptr; pt-&gt;Me=
mberOfT;`.</div></div></blockquote><div><br></div><div>Maybe I&#39;m misund=
erstanding, but neither std::unique_ptr&lt;T&gt; nor std::shared_ptr&lt;T&g=
t; have an operator T*. =C2=A0</div></div></blockquote><div><br>I could hav=
e sworn they had implicit conversions to T*. I guess I&#39;ve gotten so use=
d to writing `.get()` that I don&#39;t even notice it...<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3acb523d-cc8a-4942-8166-d80533bfd53b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3acb523d-cc8a-4942-8166-d80533bfd53b=
%40isocpp.org</a>.<br />

------=_Part_1461_1535317294.1498660377525--

------=_Part_1460_407900685.1498660377525--

.

On 28 June 2017 at 03:05, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> The point of P0352 is to not have to define any new rules. So all the
> examples Stroustrup was confused about work as if Ref<T> actually inherited
> T in the original sense.


The problem I have with the using-inheritance is that while it covers
the conversion aspect in a familiar fashion
like inheritance does, it's otherwise not at all like inheritance.
There's no base subobject. I can't override virtuals.
I'm not sure whether I can delegate to the base, and if I can, I don't
know what sort of a conversion is now applied
to calls that previously just converted *this to the base type in an
invisible fashion. I guess the latter issue may be present
in both approaches. I have no trouble understanding an operator that
kicks in for call dispatch rather than for conversions.

My take on the suggestion that customizing dot-access needs a new kind
of inheritance to be introduced into the language
is to perhaps rather not have customizable dot-access at all.

--
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/CAFk2RUZfAdACwHTyUfn-vG00fOeW08Ap7hWpS7s0x5jnv6sJxA%40mail.gmail.com.

.

------=_Part_1867_512982727.1498661890369
Content-Type: multipart/alternative;
 boundary="----=_Part_1868_311584012.1498661890370"

------=_Part_1868_311584012.1498661890370
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 10:37:50 AM UTC-4, Ville Voutilainen wrote:
>
> On 28 June 2017 at 03:05, Bengt Gustafsson
> <bengt.gu...@beamways.com <javascript:>> wrote:
> > The point of P0352 is to not have to define any new rules. So all the
> > examples Stroustrup was confused about work as if Ref<T> actually
> inherited
> > T in the original sense.
>
>
> The problem I have with the using-inheritance is that while it covers
> the conversion aspect in a familiar fashion
> like inheritance does, it's otherwise not at all like inheritance.
> There's no base subobject. I can't override virtuals.
> I'm not sure whether I can delegate to the base, and if I can, I don't
> know what sort of a conversion is now applied
> to calls that previously just converted *this to the base type in an
> invisible fashion. I guess the latter issue may be present
> in both approaches. I have no trouble understanding an operator that
> kicks in for call dispatch rather than for conversions.


I have a harder time understanding why `operator.()` is called when I don't
actually use a dot anywhere. Like the `++ref` case.

With inheritance, I can at least see that type in the base class list. If
it were a regular base class, I could follow the rules for how that `++`
works. The only difference between that and this is where the object is
stored/how the conversion takes place.


> My take on the suggestion that customizing dot-access needs a new kind
> of inheritance to be introduced into the language
> is to perhaps rather not have customizable dot-access at all.
>

That's a pretty terrible way to look at a feature. You're basically saying
"if it's not done the way I think it ought to be done, then we shouldn't do
it at all."

The questions that matter to me are:

1) Does it solve a problem?
2) Does it solve a problem that needs to be solved?
3) Does it solve that problem in a way that makes sense with the rest of
the language?
4) Does it actively break anything by existing?

It should also be noted that the "new kind of inheritance" is a general
tool, rather than overloading operator-dot. We can find ways to use this
kind of delegated inheritance in ways that you couldn't for operator-dot.

For example, consider a string class. You can give it the interface of
`string_view` by having it derive from `string_view`. But that would
require you to give it a real base class subobject, which would have to be
kept up-to-date with the actual string data.

But if you use a delegated object, the `string_view` you return from the
conversion operator could be a prvalue rather than a reference. You would
generate the view as needed. You could also pick-and-choose which
interfaces to export through *private* delegate inheritance and explicit
`using` declarations (though I don't think that's part of P0325, but it
would be a perfectly valid improvement).

That is, don't think of this feature as a way to get "operator-dot". Think
of it as a general tool that solves the problems we want "operator-dot"
for, but also potentially solves other problems.

--
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/5ceda04b-9233-4ff5-b29f-ca383f1aa5d3%40isocpp.org.

------=_Part_1868_311584012.1498661890370
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 10:37:50 AM UTC-4, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 June 201=
7 at 03:05, Bengt Gustafsson
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
qe6Gr5w5AAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">bengt.gu...@beamways.com</a><wbr>&gt; wrote:
<br>&gt; The point of P0352 is to not have to define any new rules. So all =
the
<br>&gt; examples Stroustrup was confused about work as if Ref&lt;T&gt; act=
ually inherited
<br>&gt; T in the original sense.
<br>
<br>
<br>The problem I have with the using-inheritance is that while it covers
<br>the conversion aspect in a familiar fashion
<br>like inheritance does, it&#39;s otherwise not at all like inheritance.
<br>There&#39;s no base subobject. I can&#39;t override virtuals.
<br>I&#39;m not sure whether I can delegate to the base, and if I can, I do=
n&#39;t
<br>know what sort of a conversion is now applied
<br>to calls that previously just converted *this to the base type in an
<br>invisible fashion. I guess the latter issue may be present
<br>in both approaches. I have no trouble understanding an operator that
<br>kicks in for call dispatch rather than for conversions.</blockquote><di=
v><br>I have a harder time understanding why `operator.()` is called when I=
 don&#39;t actually use a dot anywhere. Like the `++ref` case.<br><br>With =
inheritance, I can at least see that type in the base class list. If it wer=
e a regular base class, I could follow the rules for how that `++` works. T=
he only difference between that and this is where the object is stored/how =
the conversion takes place.<br>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">My take on the suggestion that customizing dot-access needs a =
new kind
<br>of inheritance to be introduced into the language
<br>is to perhaps rather not have customizable dot-access at all.
<br></blockquote><div><br>That&#39;s a pretty terrible way to look at a fea=
ture. You&#39;re basically saying &quot;if it&#39;s not done the way I thin=
k it ought to be done, then we shouldn&#39;t do it at all.&quot;<br><br>The=
 questions that matter to me are:<br><br>1) Does it solve a problem?<br>2) =
Does it solve a problem that needs to be solved?<br>3) Does it solve that p=
roblem in a way that makes sense with the rest of the language?<br>4) Does =
it actively break anything by existing?<br><br>It should also be noted that=
 the &quot;new kind of inheritance&quot; is a general tool, rather than ove=
rloading operator-dot. We can find ways to use this kind of delegated inher=
itance in ways that you couldn&#39;t for operator-dot.<br><br>For example, =
consider a string class. You can give it the interface of `string_view` by =
having it derive from `string_view`. But that would require you to give it =
a real base class subobject, which would have to be kept up-to-date with th=
e actual string data.<br><br>But if you use a delegated object, the `string=
_view` you return from the conversion operator could be a prvalue rather th=
an a reference. You would generate the view as needed. You could also pick-=
and-choose which interfaces to export through <i>private</i> delegate inher=
itance and explicit `using` declarations (though I don&#39;t think that&#39=
;s part of P0325, but it would be a perfectly valid improvement).<br><br>Th=
at is, don&#39;t think of this feature as a way to get &quot;operator-dot&q=
uot;. Think of it as a general tool that solves the problems we want &quot;=
operator-dot&quot; for, but also potentially solves other problems.<br></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5ceda04b-9233-4ff5-b29f-ca383f1aa5d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5ceda04b-9233-4ff5-b29f-ca383f1aa5d3=
%40isocpp.org</a>.<br />

------=_Part_1868_311584012.1498661890370--

------=_Part_1867_512982727.1498661890369--

.

On 2017-06-28 10:58, Nicol Bolas wrote:
> On Wednesday, June 28, 2017 at 10:37:50 AM UTC-4, Ville Voutilainen wrote:
>> I'm not sure whether I can delegate to the base, and if I can, I don't
>> know what sort of a conversion is now applied
>> to calls that previously just converted *this to the base type in an
>> invisible fashion.

The conversion is the `operator T&`, of course. This isn't *that* much
stranger than what happens with virtual base classes.

Why couldn't you delegate to the base? Do you mean something like:

  template <typename T> class Ref
  {
    void foo()
    {
      ...
      this->T::foo();
    }
  }

....? This would work with P0352 AFAIUI.

>> My take on the suggestion that customizing dot-access needs a new
>> kind of inheritance to be introduced into the language is to
>> perhaps rather not have customizable dot-access at all.
>
> That's a pretty terrible way to look at a feature. You're basically saying
> "if it's not done the way I think it ought to be done, then we shouldn't do
> it at all."
>
> The questions that matter to me are:
>
> 1) Does it solve a problem?
> 2) Does it solve a problem that needs to be solved?

Personally, I'm not convinced that the answer to these is "yes".
However, I find the potential *alternate* uses of P0352 (e.g. see below)
more interesting.

> It should also be noted that the "new kind of inheritance" is a general
> tool, rather than overloading operator-dot. We can find ways to use this
> kind of delegated inheritance in ways that you couldn't for operator-dot.

....which is another reason why I have a fairly strong preference for
P0352 over P0416. (If, that is, we need either one of them ;-).)

> For example, consider a string class. You can give it the interface of
> `string_view` by having it derive from `string_view`.

Just going to say... yeah, I think there is some very cool potential
here. (I wonder if any Qt devs are listening; it would be interesting to
know if this might be useful to QString and friends...)

ISTR one of the rationale's for `operator.` is "proxy classes". For
these, I think the P0352 way of looking at the problem, and especially
the potential to provide *multiple interfaces*, actually makes much more
sense.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2793acd2-70ab-6ec0-3b55-7cc770c09694%40gmail.com.

.

On 28 June 2017 at 17:58, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, June 28, 2017 at 10:37:50 AM UTC-4, Ville Voutilainen wrote:
>>
>> On 28 June 2017 at 03:05, Bengt Gustafsson
>> <bengt.gu...@beamways.com> wrote:
>> > The point of P0352 is to not have to define any new rules. So all the
>> > examples Stroustrup was confused about work as if Ref<T> actually
>> > inherited
>> > T in the original sense.
>>
>>
>> The problem I have with the using-inheritance is that while it covers
>> the conversion aspect in a familiar fashion
>> like inheritance does, it's otherwise not at all like inheritance.
>> There's no base subobject. I can't override virtuals.
>> I'm not sure whether I can delegate to the base, and if I can, I don't
>> know what sort of a conversion is now applied
>> to calls that previously just converted *this to the base type in an
>> invisible fashion. I guess the latter issue may be present
>> in both approaches. I have no trouble understanding an operator that
>> kicks in for call dispatch rather than for conversions.
>
>
> I have a harder time understanding why `operator.()` is called when I don't
> actually use a dot anywhere. Like the `++ref` case.
>
> With inheritance, I can at least see that type in the base class list. If it
> were a regular base class, I could follow the rules for how that `++` works.
> The only difference between that and this is where the object is stored/how
> the conversion takes place.

Yes, and the other differences between inheritance and this
delegation-conversion
are the ones that make this proposal problematic for me.

>
>>
>> My take on the suggestion that customizing dot-access needs a new kind
>> of inheritance to be introduced into the language
>> is to perhaps rather not have customizable dot-access at all.
>
>
> That's a pretty terrible way to look at a feature. You're basically saying
> "if it's not done the way I think it ought to be done, then we shouldn't do
> it at all."

Well, what you wrote in quotes would probably be a terrible way to
look at a feature,
but since that's not what I said, I can point out that if it's done in
a way completely
unacceptable to me, I'm going to oppose it, with suggestions how to remove that
opposition.

> The questions that matter to me are:
>
> 1) Does it solve a problem?
> 2) Does it solve a problem that needs to be solved?
> 3) Does it solve that problem in a way that makes sense with the rest of the
> language?
> 4) Does it actively break anything by existing?

There are rather more questions that matter to me, like
5) does it clash with existing and fundamental language facilities,
and if it does
so, is it equally fundamental?

> It should also be noted that the "new kind of inheritance" is a general
> tool, rather than overloading operator-dot. We can find ways to use this
> kind of delegated inheritance in ways that you couldn't for operator-dot.

Which is not necessarily a benefit. I have sympathy with the confusion about
an operator-dot being invoked in expressions that have no dot-access in them,
that's not exactly a strong point for either of the proposed approaches. One of
them is a member access operator that also converts, the other is a
conversion that is also
used for member access. Neither of them allows me to completely
reflect an interface,
neither of them allows me to customize how an interface is reflected,
so just because
one of them can do more tricks than the other doesn't change that they
both fall short.

> For example, consider a string class. You can give it the interface of
> `string_view` by having it derive from `string_view`. But that would require
> you to give it a real base class subobject, which would have to be kept
> up-to-date with the actual string data.
> But if you use a delegated object, the `string_view` you return from the
> conversion operator could be a prvalue rather than a reference. You would
> generate the view as needed. You could also pick-and-choose which interfaces
> to export through private delegate inheritance and explicit `using`
> declarations (though I don't think that's part of P0325, but it would be a
> perfectly valid improvement).
> That is, don't think of this feature as a way to get "operator-dot". Think
> of it as a general tool that solves the problems we want "operator-dot" for,
> but also potentially solves other problems.

Well, on that last part I agree with completely. If we get a general
mechanism for reflecting
an interface of a type onto another type, it's more plausible to put
syntax for that mechanism
in the class-head. Neither of these proposed facilities get that far,
so that's another reason
why I'm saying that perhaps we shouldn't go for customizable
dot-access, and perhaps
we shouldn't go for this dot-access-plus-conversions feature either,
but try for something
more general.

--
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/CAFk2RUbteR_5P3fwO7JaEFrGrDu4405NMC9kHgr-Xh-U699rJw%40mail.gmail.com.

.

On 28 June 2017 at 19:09, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2017-06-28 10:58, Nicol Bolas wrote:
>> On Wednesday, June 28, 2017 at 10:37:50 AM UTC-4, Ville Voutilainen wrote:
>>> I'm not sure whether I can delegate to the base, and if I can, I don't
>>> know what sort of a conversion is now applied
>>> to calls that previously just converted *this to the base type in an
>>> invisible fashion.
>
> The conversion is the `operator T&`, of course. This isn't *that* much
> stranger than what happens with virtual base classes.
>
> Why couldn't you delegate to the base? Do you mean something like:
>
>   template <typename T> class Ref
>   {
>     void foo()
>     {
>       ...
>       this->T::foo();
>     }
>   }
>
> ...? This would work with P0352 AFAIUI.

I'm talking about this:

struct X {void f();};

struct Y : using X
{
    void g()
    {
        X::f();
    }
};

What does that code do?

--
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/CAFk2RUa9S1dxQ4e1nQm6eCssHu-om0K%2B-uNpz%3DWHEgWxs204nw%40mail.gmail.com.

.

------=_Part_1368_1657147378.1498667129465
Content-Type: multipart/alternative;
 boundary="----=_Part_1369_1709886775.1498667129465"

------=_Part_1369_1709886775.1498667129465
Content-Type: text/plain; charset="UTF-8"


>
> One of
> them is a member access operator that also converts, the other is a
> conversion that is also
> used for member access.


I interpret 352 as these being independent things. The conversion function
to reference isn't used for member lookup, it's just used to get the
implicit subobject of the referring type to actually call the thing it
finds through name lookup. With that interpretation in mind...

I'm talking about this:
>
struct X {void f();};
>
> struct Y : using X
> {
>     void g()
>     {
>         X::f();
>     }
> };
>
> What does that code do?
>

I'd expect it to fail to compile with no conversion found from Y to X,
necessary to actually call f().

--
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/833e98df-93aa-4cca-9fc9-98fc76d866e8%40isocpp.org.

------=_Part_1369_1709886775.1498667129465
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">=
One of=C2=A0<br>them is a member access operator that also converts, the ot=
her is a=C2=A0<br>conversion that is also=C2=A0<br>used for member access.<=
/blockquote><div>=C2=A0</div><div>I interpret 352 as these being independen=
t things. The conversion function to reference isn&#39;t used for member lo=
okup, it&#39;s just used to get the implicit subobject of the referring typ=
e to actually call the thing it finds through name lookup. With that interp=
retation in mind...</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">I&#39;m talking about this: =C2=A0<br></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">struct X {void f();};
<br>
<br>struct Y : using X
<br>{
<br>=C2=A0 =C2=A0 void g()
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 X::f();
<br>=C2=A0 =C2=A0 }
<br>};
<br>
<br>What does that code do?
<br></blockquote><div><br></div><div>I&#39;d expect it to fail to compile w=
ith no conversion found from Y to X, necessary to actually call f().</div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/833e98df-93aa-4cca-9fc9-98fc76d866e8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/833e98df-93aa-4cca-9fc9-98fc76d866e8=
%40isocpp.org</a>.<br />

------=_Part_1369_1709886775.1498667129465--

------=_Part_1368_1657147378.1498667129465--

.

On 28 June 2017 at 19:25, Barry Revzin <barry.revzin@gmail.com> wrote:
>> One of
>> them is a member access operator that also converts, the other is a
>> conversion that is also
>> used for member access.
>
>
> I interpret 352 as these being independent things. The conversion function
> to reference isn't used for member lookup, it's just used to get the
> implicit subobject of the referring type to actually call the thing it finds
> through name lookup. With that interpretation in mind...
>
>> I'm talking about this:
>>
>> struct X {void f();};
>>
>> struct Y : using X
>> {
>>     void g()
>>     {
>>         X::f();
>>     }
>> };
>>
>> What does that code do?
>
>
> I'd expect it to fail to compile with no conversion found from Y to X,
> necessary to actually call f().


Oh indeed. So

struct Y : using X
{
    X x;
    operator X&() {return x;}
    void g()
    {
        X::f();
    }
};

Now? I guess it uses the conversion, and then calls Y::x.f()?

--
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/CAFk2RUZJG092A2QygzJZh8nijoK-Rx4%3D0vrbwJrVyYKYMoAZng%40mail.gmail.com.

.

On 2017-06-28 12:18, Ville Voutilainen wrote:
> I'm talking about this:
>
> struct X {void f();};
>
> struct Y : using X
> {
>     void g()
>     {
>         X::f();
>     }
> };
>
> What does that code do?

Fails to compile? ;-)

Assuming you implied that `operator X&` exists, obviously it does:

  (this->operator X&()).f();

Ah, but *that* isn't completely obvious either. What if X::f is virtual?
(But I think P0416 has this same problem? Although I would assume that
P0416 "obviously" would apply virtual dispatch.)

That's probably a question that needs to be raised re: P0352.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5db5ede3-932a-ebd3-ca98-371fc44b7bcf%40gmail.com.

.

------=_Part_2375_1296025857.1498668176204
Content-Type: multipart/alternative;
 boundary="----=_Part_2376_934544853.1498668176205"

------=_Part_2376_934544853.1498668176205
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 12:09:49 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-06-28 10:58, Nicol Bolas wrote:
> > On Wednesday, June 28, 2017 at 10:37:50 AM UTC-4, Ville Voutilainen
> wrote:
> >> I'm not sure whether I can delegate to the base, and if I can, I don't
> >> know what sort of a conversion is now applied
> >> to calls that previously just converted *this to the base type in an
> >> invisible fashion.
>
> The conversion is the `operator T&`, of course. This isn't *that* much
> stranger than what happens with virtual base classes.
>
> Why couldn't you delegate to the base? Do you mean something like:
>
>   template <typename T> class Ref
>   {
>     void foo()
>     {
>       ...
>       this->T::foo();
>     }
>   }
>
> ...? This would work with P0352 AFAIUI.
>
> >> My take on the suggestion that customizing dot-access needs a new
> >> kind of inheritance to be introduced into the language is to
> >> perhaps rather not have customizable dot-access at all.
> >
> > That's a pretty terrible way to look at a feature. You're basically
> saying
> > "if it's not done the way I think it ought to be done, then we shouldn't
> do
> > it at all."
> >
> > The questions that matter to me are:
> >
> > 1) Does it solve a problem?
> > 2) Does it solve a problem that needs to be solved?
>
> Personally, I'm not convinced that the answer to these is "yes".
> However, I find the potential *alternate* uses of P0352 (e.g. see below)
> more interesting.
>

I agree. I've personally never really saw the need for "smart references";
I have never had a problem with using `->` when I want to access the stored
value and `.` when I want to access the wrapper. But the fact that P0352
provides a general tool that can be used for things besides just "smart
references" gives it better motivation.

> It should also be noted that the "new kind of inheritance" is a general
> > tool, rather than overloading operator-dot. We can find ways to use this
> > kind of delegated inheritance in ways that you couldn't for
> operator-dot.
>
> ...which is another reason why I have a fairly strong preference for
> P0352 over P0416. (If, that is, we need either one of them ;-).)
>
> > For example, consider a string class. You can give it the interface of
> > `string_view` by having it derive from `string_view`.
>
> Just going to say... yeah, I think there is some very cool potential
> here. (I wonder if any Qt devs are listening; it would be interesting to
> know if this might be useful to QString and friends...)
>
> ISTR one of the rationale's for `operator.` is "proxy classes". For
> these, I think the P0352 way of looking at the problem, and especially
> the potential to provide *multiple interfaces*, actually makes much more
> sense.
>

Also, it's important to note that by using base class notation, we get a
built-in way to disambiguate between the multiple interfaces where needed.
If we relied on `operator.` to achieve the same effect, we would need to
develop a new mechanism to accomplish that effect.

--
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/f4ff1246-e5b0-4fbf-82fb-2929a5becc4a%40isocpp.org.

------=_Part_2376_934544853.1498668176205
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 12:09:49 PM UTC-4, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-06-28 10=
:58, Nicol Bolas wrote:
<br>&gt; On Wednesday, June 28, 2017 at 10:37:50 AM UTC-4, Ville Voutilaine=
n wrote:
<br>&gt;&gt; I&#39;m not sure whether I can delegate to the base, and if I =
can, I don&#39;t=20
<br>&gt;&gt; know what sort of a conversion is now applied=20
<br>&gt;&gt; to calls that previously just converted *this to the base type=
 in an=20
<br>&gt;&gt; invisible fashion.
<br>
<br>The conversion is the `operator T&amp;`, of course. This isn&#39;t *tha=
t* much
<br>stranger than what happens with virtual base classes.
<br>
<br>Why couldn&#39;t you delegate to the base? Do you mean something like:
<br>
<br>=C2=A0 template &lt;typename T&gt; class Ref
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 void foo()
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 ...
<br>=C2=A0 =C2=A0 =C2=A0 this-&gt;T::foo();
<br>=C2=A0 =C2=A0 }
<br>=C2=A0 }
<br>
<br>...? This would work with P0352 AFAIUI.
<br>
<br>&gt;&gt; My take on the suggestion that customizing dot-access needs a =
new
<br>&gt;&gt; kind of inheritance to be introduced into the language is to
<br>&gt;&gt; perhaps rather not have customizable dot-access at all.
<br>&gt;=20
<br>&gt; That&#39;s a pretty terrible way to look at a feature. You&#39;re =
basically saying=20
<br>&gt; &quot;if it&#39;s not done the way I think it ought to be done, th=
en we shouldn&#39;t do=20
<br>&gt; it at all.&quot;
<br>&gt;
<br>&gt; The questions that matter to me are:
<br>&gt;=20
<br>&gt; 1) Does it solve a problem?
<br>&gt; 2) Does it solve a problem that needs to be solved?
<br>
<br>Personally, I&#39;m not convinced that the answer to these is &quot;yes=
&quot;.
<br>However, I find the potential *alternate* uses of P0352 (e.g. see below=
)
<br>more interesting.<br></blockquote><div><br>I agree. I&#39;ve personally=
 never really saw the need for &quot;smart references&quot;; I have never h=
ad a problem with using `-&gt;` when I want to access the stored value and =
`.` when I want to access the wrapper. But the fact that P0352 provides a g=
eneral tool that can be used for things besides just &quot;smart references=
&quot; gives it better motivation.<br><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">
&gt; It should also be noted that the &quot;new kind of inheritance&quot; i=
s a general=20
<br>&gt; tool, rather than overloading operator-dot. We can find ways to us=
e this=20
<br>&gt; kind of delegated inheritance in ways that you couldn&#39;t for op=
erator-dot.
<br>
<br>...which is another reason why I have a fairly strong preference for
<br>P0352 over P0416. (If, that is, we need either one of them ;-).)
<br>
<br>&gt; For example, consider a string class. You can give it the interfac=
e of=20
<br>&gt; `string_view` by having it derive from `string_view`.
<br>
<br>Just going to say... yeah, I think there is some very cool potential
<br>here. (I wonder if any Qt devs are listening; it would be interesting t=
o
<br>know if this might be useful to QString and friends...)
<br>
<br>ISTR one of the rationale&#39;s for `operator.` is &quot;proxy classes&=
quot;. For
<br>these, I think the P0352 way of looking at the problem, and especially
<br>the potential to provide *multiple interfaces*, actually makes much mor=
e
<br>sense.<br></blockquote><div><br>Also, it&#39;s important to note that b=
y using base class notation, we get a built-in way to disambiguate between =
the multiple interfaces where needed. If we relied on `operator.` to achiev=
e the same effect, we would need to develop a new mechanism to accomplish t=
hat effect.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f4ff1246-e5b0-4fbf-82fb-2929a5becc4a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f4ff1246-e5b0-4fbf-82fb-2929a5becc4a=
%40isocpp.org</a>.<br />

------=_Part_2376_934544853.1498668176205--

------=_Part_2375_1296025857.1498668176204--

.

On 28 June 2017 at 19:37, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2017-06-28 12:18, Ville Voutilainen wrote:
>> I'm talking about this:
>>
>> struct X {void f();};
>>
>> struct Y : using X
>> {
>>     void g()
>>     {
>>         X::f();
>>     }
>> };
>>
>> What does that code do?
>
> Fails to compile? ;-)
>
> Assuming you implied that `operator X&` exists, obviously it does:
>
>   (this->operator X&()).f();
>
> Ah, but *that* isn't completely obvious either. What if X::f is virtual?
> (But I think P0416 has this same problem? Although I would assume that
> P0416 "obviously" would apply virtual dispatch.)
>
> That's probably a question that needs to be raised re: P0352.


Yep. There's been some talk about restricting using-bases and usual
bases so that one base
can't be both. I wonder whether things like this are the reason for
it. I don't have such restrictions
with the operator-dot proposal.

Envision something like this:

struct B {void f() {do_f();} virtual void do_f() {}};

struct X : B, using B
{
    B b;
    operator B&() {return b;}
    void do_f() override;
    void g() {B::f();} // who ya gonna call? Ghostbusters? Sure, it
might be ambiguous.
};

And no, I'm not entirely sure I understand what the operator-dot
proposal does in such cases either.

--
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/CAFk2RUbXhFp1VKc-J%2BGgSXCZmvtLfbF%2BS8Po4Thet9JpDBGSNQ%40mail.gmail.com.

.

------=_Part_336_422775649.1498668672642
Content-Type: multipart/alternative;
 boundary="----=_Part_337_2142887011.1498668672643"

------=_Part_337_2142887011.1498668672643
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 12:37:30 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-06-28 12:18, Ville Voutilainen wrote:
> > I'm talking about this:
> >
> > struct X {void f();};
> >
> > struct Y : using X
> > {
> >     void g()
> >     {
> >         X::f();
> >     }
> > };
> >
> > What does that code do?
>
> Fails to compile? ;-)
>
> Assuming you implied that `operator X&` exists, obviously it does:
>
>   (this->operator X&()).f();
>
> Ah, but *that* isn't completely obvious either. What if X::f is virtual?
> (But I think P0416 has this same problem? Although I would assume that
> P0416 "obviously" would apply virtual dispatch.)
>

I think it would be good to provide a more clear example of the question:

struct base { virtual void f(); };

struct derived : base { virtual void f() override; };

struct user : using base
{
  derived d;
  operator base&() {return d;}

  void g()
  {
    base::f();
  }
};

We know that if you do `some_user.f()`, we should call `derived::f` via
virtual dispatch. But what exactly happens in `g`?

I think the only reasonable answer would be that it calls exactly what it
would have called if `Y` had a base class subobject of type `base`. That
is, it will make a non-virtual dispatch call to `base::f`.

The only thing delegation ought to change is how we get the object to
invoke the operation on. Whether it does virtual or non-virtual dispatch
and things like that should work exactly as if it were a regular base class
of the type.

That's the whole idea of P0352 as a feature.

That's probably a question that needs to be raised re: P0352.
>
> --
> Matthew
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fe3d24b1-9f51-4acb-bafe-868ac735f44f%40isocpp.org.

------=_Part_337_2142887011.1498668672643
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 12:37:30 PM UTC-4, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-06-28 12=
:18, Ville Voutilainen wrote:
<br>&gt; I&#39;m talking about this:
<br>&gt;=20
<br>&gt; struct X {void f();};
<br>&gt;=20
<br>&gt; struct Y : using X
<br>&gt; {
<br>&gt; =C2=A0 =C2=A0 void g()
<br>&gt; =C2=A0 =C2=A0 {
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 X::f();
<br>&gt; =C2=A0 =C2=A0 }
<br>&gt; };
<br>&gt;=20
<br>&gt; What does that code do?
<br>
<br>Fails to compile? ;-)
<br>
<br>Assuming you implied that `operator X&amp;` exists, obviously it does:
<br>
<br>=C2=A0 (this-&gt;operator X&amp;()).f();
<br>
<br>Ah, but *that* isn&#39;t completely obvious either. What if X::f is vir=
tual?
<br>(But I think P0416 has this same problem? Although I would assume that
<br>P0416 &quot;obviously&quot; would apply virtual dispatch.)
<br></blockquote><div><br>I think it would be good to provide a more clear =
example of the question:<br><br><div style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">base</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">virtual</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> de=
rived </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">base</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">virtual</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">override</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> user </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">us=
ing</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">base</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 derived d</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">base</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;()</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;}</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> g</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">base</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};<=
/span></div></code></div><br>We know that if you do `some_user.f()`, we sho=
uld call `derived::f` via virtual dispatch. But what exactly happens in `g`=
?<br><br>I think the only reasonable answer would be that it calls exactly =
what it would have called if `Y` had a base class subobject of type `base`.=
 That is, it will make a non-virtual dispatch call to `base::f`.<br><br>The=
 only thing delegation ought to change is how we get the object to invoke t=
he operation on. Whether it does virtual or non-virtual dispatch and things=
 like that should work exactly as if it were a regular base class of the ty=
pe.<br><br>That&#39;s the whole idea of P0352 as a feature.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">
That&#39;s probably a question that needs to be raised re: P0352.
<br>
<br>--=20
<br>Matthew
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fe3d24b1-9f51-4acb-bafe-868ac735f44f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fe3d24b1-9f51-4acb-bafe-868ac735f44f=
%40isocpp.org</a>.<br />

------=_Part_337_2142887011.1498668672643--

------=_Part_336_422775649.1498668672642--

.

------=_Part_2953_1020253912.1498669056833
Content-Type: multipart/alternative;
 boundary="----=_Part_2954_640505552.1498669056833"

------=_Part_2954_640505552.1498669056833
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 12:46:09 PM UTC-4, Ville Voutilainen wrote:
>
> Yep. There's been some talk about restricting using-bases and usual
> bases so that one base
> can't be both. I wonder whether things like this are the reason for
> it. I don't have such restrictions
> with the operator-dot proposal.
>
> Envision something like this:
>
> struct B {void f() {do_f();} virtual void do_f() {}};
>
> struct X : B, using B
> {
>     B b;
>     operator B&() {return b;}
>     void do_f() override;
>     void g() {B::f();} // who ya gonna call? Ghostbusters? Sure, it
> might be ambiguous.
> };
>

I'm fairly sure that should be forbidden, in the exact same way as we
forbid a class from having two direct base classes of the same type. So if
it would be broken if you took out `using`, then it should still be broken
with `using`.

And no, I'm not entirely sure I understand what the operator-dot
> proposal does in such cases either.
>

--
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/8e9f3eea-157a-4f01-a7b2-d19dcaa01abe%40isocpp.org.

------=_Part_2954_640505552.1498669056833
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 12:46:09 PM UTC-4, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yep. There&#39=
;s been some talk about restricting using-bases and usual
<br>bases so that one base
<br>can&#39;t be both. I wonder whether things like this are the reason for
<br>it. I don&#39;t have such restrictions
<br>with the operator-dot proposal.
<br>
<br>Envision something like this:
<br>
<br>struct B {void f() {do_f();} virtual void do_f() {}};
<br>
<br>struct X : B, using B
<br>{
<br>=C2=A0 =C2=A0 B b;
<br>=C2=A0 =C2=A0 operator B&amp;() {return b;}
<br>=C2=A0 =C2=A0 void do_f() override;
<br>=C2=A0 =C2=A0 void g() {B::f();} // who ya gonna call? Ghostbusters? Su=
re, it
<br>might be ambiguous.
<br>};
<br></blockquote><div><br>I&#39;m fairly sure that should be forbidden, in =
the exact same way as we forbid a class from having two direct base classes=
 of the same type. So if it would be broken if you took out `using`, then i=
t should still be broken with `using`.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
And no, I&#39;m not entirely sure I understand what the operator-dot
<br>proposal does in such cases either.
<br></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8e9f3eea-157a-4f01-a7b2-d19dcaa01abe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e9f3eea-157a-4f01-a7b2-d19dcaa01abe=
%40isocpp.org</a>.<br />

------=_Part_2954_640505552.1498669056833--

------=_Part_2953_1020253912.1498669056833--

.

------=_Part_1657_539095784.1498669239851
Content-Type: multipart/alternative;
 boundary="----=_Part_1658_607674318.1498669239852"

------=_Part_1658_607674318.1498669239852
Content-Type: text/plain; charset="UTF-8"


>
> Oh indeed. So
>
> struct Y : using X
> {
>     X x;
>     operator X&() {return x;}
>     void g()
>     {
>         X::f();
>     }
> };
>
> Now? I guess it uses the conversion, and then calls Y::x.f()?
>

Yeah, Y.operator X&().f()

struct B {void f() {do_f();} virtual void do_f() {}};
> struct X : B, using B
> {
>     B b;
>     operator B&() {return b;}
>     void do_f() override;
>     void g() {B::f();} // who ya gonna call? Ghostbusters? Sure, it
> might be ambiguous.
> };


Cracked up at the comment, nicely done!

I'd expect it to be an error. Lookup on f() finds it in two different base
classes, so we give up and call it ambiguous. Same reason that this is an
error today:

struct A { void f(); };
struct B { void f(int ); };
struct C : A, B {
    void g() { f(); }
};




--
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/64d16444-558c-4b2f-80b2-290eb6e41c8f%40isocpp.org.

------=_Part_1658_607674318.1498669239852
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;">Oh indeed. So
<br>
<br>struct Y : using X
<br>{
<br>=C2=A0 =C2=A0 X x;
<br>=C2=A0 =C2=A0 operator X&amp;() {return x;}
<br>=C2=A0 =C2=A0 void g()
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 X::f();
<br>=C2=A0 =C2=A0 }
<br>};
<br>
<br>Now? I guess it uses the conversion, and then calls Y::x.f()?
<br></blockquote><div><br></div><div>Yeah, Y.operator X&amp;().f()</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">struc=
t B {void f() {do_f();} virtual void do_f() {}};=C2=A0<br>struct X : B, usi=
ng B=C2=A0<br>{=C2=A0<br>=C2=A0 =C2=A0 B b;=C2=A0<br>=C2=A0 =C2=A0 operator=
 B&amp;() {return b;}=C2=A0<br>=C2=A0 =C2=A0 void do_f() override;=C2=A0<br=
>=C2=A0 =C2=A0 void g() {B::f();} // who ya gonna call? Ghostbusters? Sure,=
 it=C2=A0<br>might be ambiguous.=C2=A0<br>};=C2=A0</blockquote><div><br></d=
iv><div>Cracked up at the comment, nicely done!=C2=A0</div><div><br></div><=
div>I&#39;d expect it to be an error. Lookup on f() finds it in two differe=
nt base classes, so we give up and call it ambiguous. Same reason that this=
 is an error today:</div><div><br></div><div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> A </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> B </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> C </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> A</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 B </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> g</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><=
/font></div></code></div><div><br></div><br>=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&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/64d16444-558c-4b2f-80b2-290eb6e41c8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/64d16444-558c-4b2f-80b2-290eb6e41c8f=
%40isocpp.org</a>.<br />

------=_Part_1658_607674318.1498669239852--

------=_Part_1657_539095784.1498669239851--

.

------=_Part_2978_176534807.1498669236436
Content-Type: multipart/alternative;
 boundary="----=_Part_2979_1436044097.1498669236436"

------=_Part_2979_1436044097.1498669236436
Content-Type: text/plain; charset="UTF-8"



On Wednesday, June 28, 2017 at 12:36:53 PM UTC-4, Ville Voutilainen wrote:
>
> On 28 June 2017 at 19:25, Barry Revzin <barry....@gmail.com <javascript:>>
> wrote:
> >> One of
> >> them is a member access operator that also converts, the other is a
> >> conversion that is also
> >> used for member access.
> >
> >
> > I interpret 352 as these being independent things. The conversion
> function
> > to reference isn't used for member lookup, it's just used to get the
> > implicit subobject of the referring type to actually call the thing it
> finds
> > through name lookup. With that interpretation in mind...
> >
> >> I'm talking about this:
> >>
> >> struct X {void f();};
> >>
> >> struct Y : using X
> >> {
> >>     void g()
> >>     {
> >>         X::f();
> >>     }
> >> };
> >>
> >> What does that code do?
> >
> >
> > I'd expect it to fail to compile with no conversion found from Y to X,
> > necessary to actually call f().
>
>
> Oh indeed. So
>
> struct Y : using X
> {
>     X x;
>     operator X&() {return x;}
>     void g()
>     {
>         X::f();
>     }
> };
>
> Now? I guess it uses the conversion, and then calls Y::x.f()?
>

Yes, that's the idea. Anytime the standard would say that an expression
refers to a base class subobject, it instead invokes the conversion
operator appropriate to the base class's type to get the object to act on.

--
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/6da4760a-7d3f-499a-9da3-e00b2be998e4%40isocpp.org.

------=_Part_2979_1436044097.1498669236436
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, June 28, 2017 at 12:36:53 PM UTC-4, =
Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 =
June 2017 at 19:25, Barry Revzin &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"dGH79xtAAAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">barry....@gmail.com</a>&gt; wrote:
<br>&gt;&gt; One of
<br>&gt;&gt; them is a member access operator that also converts, the other=
 is a
<br>&gt;&gt; conversion that is also
<br>&gt;&gt; used for member access.
<br>&gt;
<br>&gt;
<br>&gt; I interpret 352 as these being independent things. The conversion =
function
<br>&gt; to reference isn&#39;t used for member lookup, it&#39;s just used =
to get the
<br>&gt; implicit subobject of the referring type to actually call the thin=
g it finds
<br>&gt; through name lookup. With that interpretation in mind...
<br>&gt;
<br>&gt;&gt; I&#39;m talking about this:
<br>&gt;&gt;
<br>&gt;&gt; struct X {void f();};
<br>&gt;&gt;
<br>&gt;&gt; struct Y : using X
<br>&gt;&gt; {
<br>&gt;&gt; =C2=A0 =C2=A0 void g()
<br>&gt;&gt; =C2=A0 =C2=A0 {
<br>&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 X::f();
<br>&gt;&gt; =C2=A0 =C2=A0 }
<br>&gt;&gt; };
<br>&gt;&gt;
<br>&gt;&gt; What does that code do?
<br>&gt;
<br>&gt;
<br>&gt; I&#39;d expect it to fail to compile with no conversion found from=
 Y to X,
<br>&gt; necessary to actually call f().
<br>
<br>
<br>Oh indeed. So
<br>
<br>struct Y : using X
<br>{
<br>=C2=A0 =C2=A0 X x;
<br>=C2=A0 =C2=A0 operator X&amp;() {return x;}
<br>=C2=A0 =C2=A0 void g()
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 X::f();
<br>=C2=A0 =C2=A0 }
<br>};
<br>
<br>Now? I guess it uses the conversion, and then calls Y::x.f()?
<br></blockquote><div><br>Yes, that&#39;s the idea. Anytime the standard wo=
uld say that an expression refers to a base class subobject, it instead inv=
okes the conversion operator appropriate to the base class&#39;s type to ge=
t the object to act on.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6da4760a-7d3f-499a-9da3-e00b2be998e4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6da4760a-7d3f-499a-9da3-e00b2be998e4=
%40isocpp.org</a>.<br />

------=_Part_2979_1436044097.1498669236436--

------=_Part_2978_176534807.1498669236436--

.

On 28 June 2017 at 19:57, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, June 28, 2017 at 12:46:09 PM UTC-4, Ville Voutilainen wrote:
>>
>> Yep. There's been some talk about restricting using-bases and usual
>> bases so that one base
>> can't be both. I wonder whether things like this are the reason for
>> it. I don't have such restrictions
>> with the operator-dot proposal.
>>
>> Envision something like this:
>>
>> struct B {void f() {do_f();} virtual void do_f() {}};
>>
>> struct X : B, using B
>> {
>>     B b;
>>     operator B&() {return b;}
>>     void do_f() override;
>>     void g() {B::f();} // who ya gonna call? Ghostbusters? Sure, it
>> might be ambiguous.
>> };
>
>
> I'm fairly sure that should be forbidden, in the exact same way as we forbid
> a class from having two direct base classes of the same type. So if it would
> be broken if you took out `using`, then it should still be broken with
> `using`.


Right. The other proposal places no restrictions on what I can derive from.

--
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/CAFk2RUYx%2BYLbdpJ103Xq0s4HHwL%2BbV-sgY8BtNoxDYM2zd1n2w%40mail.gmail.com.

.

------=_Part_2855_1846276380.1498670374962
Content-Type: multipart/alternative;
 boundary="----=_Part_2856_596497700.1498670374962"

------=_Part_2856_596497700.1498670374962
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 1:08:58 PM UTC-4, Ville Voutilainen wrote:
>
> On 28 June 2017 at 19:57, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > On Wednesday, June 28, 2017 at 12:46:09 PM UTC-4, Ville Voutilainen
> wrote:
> >>
> >> Yep. There's been some talk about restricting using-bases and usual
> >> bases so that one base
> >> can't be both. I wonder whether things like this are the reason for
> >> it. I don't have such restrictions
> >> with the operator-dot proposal.
> >>
> >> Envision something like this:
> >>
> >> struct B {void f() {do_f();} virtual void do_f() {}};
> >>
> >> struct X : B, using B
> >> {
> >>     B b;
> >>     operator B&() {return b;}
> >>     void do_f() override;
> >>     void g() {B::f();} // who ya gonna call? Ghostbusters? Sure, it
> >> might be ambiguous.
> >> };
> >
> >
> > I'm fairly sure that should be forbidden, in the exact same way as we
> forbid
> > a class from having two direct base classes of the same type. So if it
> would
> > be broken if you took out `using`, then it should still be broken with
> > `using`.
>
>
> Right. The other proposal places no restrictions on what I can derive
> from.
>

Base classes represent an "is-a" relationship. Why would you need to proxy
*yourself*?

It's a restriction to note. I just don't think it will matter in practice.

--
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/d175efc1-9b84-4064-8bbe-e731037503cd%40isocpp.org.

------=_Part_2856_596497700.1498670374962
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 1:08:58 PM UTC-4, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 June 2017=
 at 19:57, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"OfFwKtxBAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; On Wednesday, June 28, 2017 at 12:46:09 PM UTC-4, Ville Voutilaine=
n wrote:
<br>&gt;&gt;
<br>&gt;&gt; Yep. There&#39;s been some talk about restricting using-bases =
and usual
<br>&gt;&gt; bases so that one base
<br>&gt;&gt; can&#39;t be both. I wonder whether things like this are the r=
eason for
<br>&gt;&gt; it. I don&#39;t have such restrictions
<br>&gt;&gt; with the operator-dot proposal.
<br>&gt;&gt;
<br>&gt;&gt; Envision something like this:
<br>&gt;&gt;
<br>&gt;&gt; struct B {void f() {do_f();} virtual void do_f() {}};
<br>&gt;&gt;
<br>&gt;&gt; struct X : B, using B
<br>&gt;&gt; {
<br>&gt;&gt; =C2=A0 =C2=A0 B b;
<br>&gt;&gt; =C2=A0 =C2=A0 operator B&amp;() {return b;}
<br>&gt;&gt; =C2=A0 =C2=A0 void do_f() override;
<br>&gt;&gt; =C2=A0 =C2=A0 void g() {B::f();} // who ya gonna call? Ghostbu=
sters? Sure, it
<br>&gt;&gt; might be ambiguous.
<br>&gt;&gt; };
<br>&gt;
<br>&gt;
<br>&gt; I&#39;m fairly sure that should be forbidden, in the exact same wa=
y as we forbid
<br>&gt; a class from having two direct base classes of the same type. So i=
f it would
<br>&gt; be broken if you took out `using`, then it should still be broken =
with
<br>&gt; `using`.
<br>
<br>
<br>Right. The other proposal places no restrictions on what I can derive f=
rom.
<br></blockquote><div><br>Base classes represent an &quot;is-a&quot; relati=
onship. Why would you need to proxy <i>yourself</i>?<br><br>It&#39;s a rest=
riction to note. I just don&#39;t think it will matter in practice.<br></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d175efc1-9b84-4064-8bbe-e731037503cd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d175efc1-9b84-4064-8bbe-e731037503cd=
%40isocpp.org</a>.<br />

------=_Part_2856_596497700.1498670374962--

------=_Part_2855_1846276380.1498670374962--

.

On 2017-06-28 09:30, Nicol Bolas wrote:
> On Wednesday, June 28, 2017 at 7:50:12 AM UTC-4, Matthew Woehlke wrote:
>> What's that? "Performance reasons", you say?
>
> The only performance benefit you could get is allowing the compiler to
> de-virtualize virtual functions on the type. And you could get the same
> effect by just saying that class-level `final` means that all virtual
> functions, inherited or not, are implicitly declared `final`.

Are you sure? I could imagine there may exist some case where the
compiler knowing that a `Final*` is most definitely *really* a `Final*`
and not a `MoreDerived*` is helpful.

If nothing else, it would allow constexpr evaluation of a dynamic_cast.
(Presumably this would have to occur in template code, that the coder
didn't just use a static_cast in the first place.)

(That said, I tend to agree with you that I could live with the feature
being totally removed...)

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f2b3a2e6-8e6f-336f-92d2-e5c59fc0e530%40gmail.com.

.

On 2017-06-28 12:46, Ville Voutilainen wrote:
> On 28 June 2017 at 19:37, Matthew Woehlke wrote:
>> Ah, but *that* isn't completely obvious either. What if X::f is virtual?
>> (But I think P0416 has this same problem? Although I would assume that
>> P0416 "obviously" would apply virtual dispatch.)
>>
>> That's probably a question that needs to be raised re: P0352.
>
> Yep. There's been some talk about restricting using-bases and usual
> bases so that one base
> can't be both. I wonder whether things like this are the reason for
> it. I don't have such restrictions
> with the operator-dot proposal.

I don't think we're talking about the same problem. I'm talking about:

  struct A { virtual void foo(); }
  struct B : A { virtual void foo(); }

  class R : using A
  {
    A* a;
  public:
    R(A* r) : a{r} {}
    operator A&() { return *a; }
    void foo() { A::foo(); }
  }

  auto r = R{new B};
  r.foo();

Now... does that call A::foo or B::foo? Given similar P0416 code, I
would certainly expect it calls B::foo! It gets a little funky with the
P0352 example, above, because you wrote `A::foo`. In the P0352 usage,
that means 'delegate to the pseudo-base', but traditionally it *also*
means to stop virtual dispatch at `A`. Does it, or does it not, still
have that meaning in this case?

I don't know. Conceivably we want to allow both (which we certainly can
by requiring the user to explicitly invoke the conversion operator), but
it's an open question.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fabf76b7-293c-2e19-148e-5c26a1212ebe%40gmail.com.

.

On 2017-06-28 13:08, Ville Voutilainen wrote:
> On 28 June 2017 at 19:57, Nicol Bolas wrote:
>> On Wednesday, June 28, 2017 at 12:46:09 PM UTC-4, Ville Voutilainen wrote:
>>> Envision something like this:
>>>
>>> struct B {void f() {do_f();} virtual void do_f() {}};
>>>
>>> struct X : B, using B
>>> {
>>>     B b;
>>>     operator B&() {return b;}
>>>     void do_f() override;
>>>     void g() {B::f();} // who ya gonna call? Ghostbusters? Sure, it
>>> might be ambiguous.
>>> };
>>
>> I'm fairly sure that should be forbidden, in the exact same way as we forbid
>> a class from having two direct base classes of the same type. So if it would
>> be broken if you took out `using`, then it should still be broken with
>> `using`.
>
> Right. The other proposal places no restrictions on what I can derive from.

I'm not sure that's a *feature*. Either way (P0352 / P0416) you've
created a mess. P0352 makes it easy and obvious to make that ill-formed.

--
Matthew

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5b22da2e-de31-2f73-ea42-d5ed021b599c%40gmail.com.

.

------=_Part_2404_2008219597.1498671733483
Content-Type: multipart/alternative;
 boundary="----=_Part_2405_2095022644.1498671733483"

------=_Part_2405_2095022644.1498671733483
Content-Type: text/plain; charset="UTF-8"



On Wednesday, June 28, 2017 at 1:24:05 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-06-28 09:30, Nicol Bolas wrote:
> > On Wednesday, June 28, 2017 at 7:50:12 AM UTC-4, Matthew Woehlke wrote:
> >> What's that? "Performance reasons", you say?
> >
> > The only performance benefit you could get is allowing the compiler to
> > de-virtualize virtual functions on the type. And you could get the same
> > effect by just saying that class-level `final` means that all virtual
> > functions, inherited or not, are implicitly declared `final`.
>
> Are you sure? I could imagine there may exist some case where the
> compiler knowing that a `Final*` is most definitely *really* a `Final*`
> and not a `MoreDerived*` is helpful.
>

There's at least one other case: if the class uses virtual inheritance, the
compiler can turn accesses to virtual base classes into static offsets.

So let's recoup that. If a class is declared `final`, then:

1) All inherited virtual members are implicitly declared `final`.
2) Classes which derive from the `final` class may not `virtual`ly inherit
from any base classes that the `final` class `virtual`ly inherits from.

--
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/82c0c94b-28dd-4539-8464-9276b1daf80c%40isocpp.org.

------=_Part_2405_2095022644.1498671733483
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, June 28, 2017 at 1:24:05 PM UTC-4, M=
atthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-0=
6-28 09:30, Nicol Bolas wrote:
<br>&gt; On Wednesday, June 28, 2017 at 7:50:12 AM UTC-4, Matthew Woehlke w=
rote:
<br>&gt;&gt; What&#39;s that? &quot;Performance reasons&quot;, you say?
<br>&gt;=20
<br>&gt; The only performance benefit you could get is allowing the compile=
r to=20
<br>&gt; de-virtualize virtual functions on the type. And you could get the=
 same=20
<br>&gt; effect by just saying that class-level `final` means that all virt=
ual=20
<br>&gt; functions, inherited or not, are implicitly declared `final`.
<br>
<br>Are you sure? I could imagine there may exist some case where the
<br>compiler knowing that a `Final*` is most definitely *really* a `Final*`
<br>and not a `MoreDerived*` is helpful.<br></blockquote><div><br>There&#39=
;s at least one other case: if the class uses virtual inheritance, the comp=
iler can turn accesses to virtual base classes into static offsets.<br><br>=
So let&#39;s recoup that. If a class is declared `final`, then:<br><br>1) A=
ll inherited virtual members are implicitly declared `final`.<br>2) Classes=
 which derive from the `final` class may not `virtual`ly inherit from any b=
ase classes that the `final` class `virtual`ly inherits from.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/82c0c94b-28dd-4539-8464-9276b1daf80c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/82c0c94b-28dd-4539-8464-9276b1daf80c=
%40isocpp.org</a>.<br />

------=_Part_2405_2095022644.1498671733483--

------=_Part_2404_2008219597.1498671733483--

.

------=_Part_2816_1993160278.1498672504803
Content-Type: multipart/alternative;
 boundary="----=_Part_2817_1575302645.1498672504804"

------=_Part_2817_1575302645.1498672504804
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 1:38:15 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-06-28 12:46, Ville Voutilainen wrote:
> > On 28 June 2017 at 19:37, Matthew Woehlke wrote:
> >> Ah, but *that* isn't completely obvious either. What if X::f is
> virtual?
> >> (But I think P0416 has this same problem? Although I would assume that
> >> P0416 "obviously" would apply virtual dispatch.)
> >>
> >> That's probably a question that needs to be raised re: P0352.
> >
> > Yep. There's been some talk about restricting using-bases and usual
> > bases so that one base
> > can't be both. I wonder whether things like this are the reason for
> > it. I don't have such restrictions
> > with the operator-dot proposal.
>
> I don't think we're talking about the same problem. I'm talking about:
>
>   struct A { virtual void foo(); }
>   struct B : A { virtual void foo(); }
>
>   class R : using A
>   {
>     A* a;
>   public:
>     R(A* r) : a{r} {}
>     operator A&() { return *a; }
>     void foo() { A::foo(); }
>   }
>
>   auto r = R{new B};
>   r.foo();
>
> Now... does that call A::foo or B::foo? Given similar P0416 code, I
> would certainly expect it calls B::foo! It gets a little funky with the
> P0352 example, above, because you wrote `A::foo`. In the P0352 usage,
> that means 'delegate to the pseudo-base', but traditionally it *also*
> means to stop virtual dispatch at `A`. Does it, or does it not, still
> have that meaning in this case?
>
> I don't know. Conceivably we want to allow both (which we certainly can
> by requiring the user to explicitly invoke the conversion operator), but
> it's an open question.
>

Perhaps we can allow `A::virtual foo` or some such to mean that we want to
allow virtual dispatch, if `foo` is a virtual function.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9e05fbb5-afb4-484e-8a3e-ca13e5af477a%40isocpp.org.

------=_Part_2817_1575302645.1498672504804
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 1:38:15 PM UTC-4, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-06-28 12:=
46, Ville Voutilainen wrote:
<br>&gt; On 28 June 2017 at 19:37, Matthew Woehlke wrote:
<br>&gt;&gt; Ah, but *that* isn&#39;t completely obvious either. What if X:=
:f is virtual?
<br>&gt;&gt; (But I think P0416 has this same problem? Although I would ass=
ume that
<br>&gt;&gt; P0416 &quot;obviously&quot; would apply virtual dispatch.)
<br>&gt;&gt;
<br>&gt;&gt; That&#39;s probably a question that needs to be raised re: P03=
52.
<br>&gt;=20
<br>&gt; Yep. There&#39;s been some talk about restricting using-bases and =
usual
<br>&gt; bases so that one base
<br>&gt; can&#39;t be both. I wonder whether things like this are the reaso=
n for
<br>&gt; it. I don&#39;t have such restrictions
<br>&gt; with the operator-dot proposal.
<br>
<br>I don&#39;t think we&#39;re talking about the same problem. I&#39;m tal=
king about:
<br>
<br>=C2=A0 struct A { virtual void foo(); }
<br>=C2=A0 struct B : A { virtual void foo(); }
<br>
<br>=C2=A0 class R : using A
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 A* a;
<br>=C2=A0 public:
<br>=C2=A0 =C2=A0 R(A* r) : a{r} {}
<br>=C2=A0 =C2=A0 operator A&amp;() { return *a; }
<br>=C2=A0 =C2=A0 void foo() { A::foo(); }
<br>=C2=A0 }
<br>
<br>=C2=A0 auto r =3D R{new B};
<br>=C2=A0 r.foo();
<br>
<br>Now... does that call A::foo or B::foo? Given similar P0416 code, I
<br>would certainly expect it calls B::foo! It gets a little funky with the
<br>P0352 example, above, because you wrote `A::foo`. In the P0352 usage,
<br>that means &#39;delegate to the pseudo-base&#39;, but traditionally it =
*also*
<br>means to stop virtual dispatch at `A`. Does it, or does it not, still
<br>have that meaning in this case?
<br>
<br>I don&#39;t know. Conceivably we want to allow both (which we certainly=
 can
<br>by requiring the user to explicitly invoke the conversion operator), bu=
t
<br>it&#39;s an open question.
<br></blockquote><div><br>Perhaps we can allow `A::virtual foo` or some suc=
h to mean that we want to allow virtual dispatch, if `foo` is a virtual fun=
ction.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9e05fbb5-afb4-484e-8a3e-ca13e5af477a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e05fbb5-afb4-484e-8a3e-ca13e5af477a=
%40isocpp.org</a>.<br />

------=_Part_2817_1575302645.1498672504804--

------=_Part_2816_1993160278.1498672504803--

.

On 28 June 2017 at 20:19, Nicol Bolas <jmckesson@gmail.com> wrote:
> Base classes represent an "is-a" relationship. Why would you need to proxy
> yourself?

That's a funny question. Fairly many proxies look like this:

struct DaInterface
{
    virtual void mah_bucketz() = 0;
};

struct DaProxy : DaInterface
{
    DaInterface* proxy_target;
    void mah_bucketz()
    {
        // preamble code
        proxy_target->mah_bucketz();
        // post-amble code
    }
};

I guess I could turn that inheritance into delegation, except I just
lost the capability to override, since a using-base
doesn't do that. The operator-dot proposal isn't all that suitable for
this either, because for multiple interface functions,
I might have different preambles and post-ambles so the operator dot
is not the place to write those in.

But perhaps proxies aren't what these proposals are for.

--
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/CAFk2RUaWhOTNAgTxQiuu5s01-3d-b%3DWa8g5Rn323XethVF36Gg%40mail.gmail.com.

.

On 06/28/2017 01:48 PM, Matthew Woehlke wrote:
> Historically, whether to write `this->` in front of member access has
> been a matter of style.

Not quite: If you want to name a member from a dependent base class,
a plain unqualified-id doesn't work, so "this->x" is one (common)
way to make the id-expression dependent.

Jens

--
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/595414F2.90403%40gmx.net.

.

On 28 June 2017 at 20:40, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> Right. The other proposal places no restrictions on what I can derive from.
>
> I'm not sure that's a *feature*. Either way (P0352 / P0416) you've
> created a mess. P0352 makes it easy and obvious to make that ill-formed.


There's a very good chance that what you call a "mess" is exactly the
right solution to the problem at hand, though.

--
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/CAFk2RUaAZsNgu%3Dc5ERNsMEWvrX4xWF9DBg6Aj901i8neV4mq2A%40mail.gmail.com.

.

------=_Part_3062_1511189649.1498683816004
Content-Type: multipart/alternative;
 boundary="----=_Part_3063_1359268142.1498683816004"

------=_Part_3063_1359268142.1498683816004
Content-Type: text/plain; charset="UTF-8"

On Wednesday, June 28, 2017 at 2:27:10 PM UTC-4, Ville Voutilainen wrote:
>
> On 28 June 2017 at 20:19, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > Base classes represent an "is-a" relationship. Why would you need to
> proxy
> > yourself?
>
> That's a funny question. Fairly many proxies look like this:
>

When I said "proxy", I was referring to the general idea of an object
taking on the interface and general behavior of another. The standard
problem operator-dot is intended to solve is "smart reference" proxies.

My question therefore is why would a smart reference type need to be a
smart reference to one of its base classes? If you're using this for proxy
iterators, why would you be deriving from the type you're proxying?

--
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/a8830029-0f94-44b0-a777-bd4e6812bd2b%40isocpp.org.

------=_Part_3063_1359268142.1498683816004
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, June 28, 2017 at 2:27:10 PM UTC-4, Ville Vou=
tilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 28 June 2017=
 at 20:19, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"MnJ9oSBGAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; Base classes represent an &quot;is-a&quot; relationship. Why would=
 you need to proxy
<br>&gt; yourself?
<br>
<br>That&#39;s a funny question. Fairly many proxies look like this:
<br></blockquote><div><br>When I said &quot;proxy&quot;, I was referring to=
 the general idea of an object taking on the interface and general behavior=
 of another. The standard problem operator-dot is intended to solve is &quo=
t;smart reference&quot; proxies.<br><br>My question therefore is why would =
a smart reference type need to be a smart reference to one of its base clas=
ses? If you&#39;re using this for proxy iterators, why would you be derivin=
g from the type you&#39;re proxying?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a8830029-0f94-44b0-a777-bd4e6812bd2b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8830029-0f94-44b0-a777-bd4e6812bd2b=
%40isocpp.org</a>.<br />

------=_Part_3063_1359268142.1498683816004--

------=_Part_3062_1511189649.1498683816004--

.

On 06/28/2017 06:15 PM, Ville Voutilainen wrote:
> On 28 June 2017 at 17:58, Nicol Bolas <jmckesson@gmail.com> wrote:

>> The questions that matter to me are:
>>
>> 1) Does it solve a problem?
>> 2) Does it solve a problem that needs to be solved?
>> 3) Does it solve that problem in a way that makes sense with the rest of the
>> language?
>> 4) Does it actively break anything by existing?
>
> There are rather more questions that matter to me, like
> 5) does it clash with existing and fundamental language facilities,
> and if it does
> so, is it equally fundamental?

Well, there's also "is the machinery we're introducing to
solve the problem worth it?"

I find the P0252R2 / P0416R1 machinery too involved for this
fringe feature.

(In case someone cares, I feel the same about the Coroutines TS,
although the feature is more broadly useful.)

And if we don't get consensus for either of the smart-references
proposals, life will go on.  Very much so.  I'd rather spend
WG21 committee time on concepts than on smart references.

Jens

--
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/59541C64.5070501%40gmx.net.

.

On 29 June 2017 at 00:03, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, June 28, 2017 at 2:27:10 PM UTC-4, Ville Voutilainen wrote:
>>
>> On 28 June 2017 at 20:19, Nicol Bolas <jmck...@gmail.com> wrote:
>> > Base classes represent an "is-a" relationship. Why would you need to
>> > proxy
>> > yourself?
>>
>> That's a funny question. Fairly many proxies look like this:
>
>
> When I said "proxy", I was referring to the general idea of an object taking
> on the interface and general behavior of another. The standard problem
> operator-dot is intended to solve is "smart reference" proxies.
>
> My question therefore is why would a smart reference type need to be a smart
> reference to one of its base classes? If you're using this for proxy
> iterators, why would you be deriving from the type you're proxying?

I don't know. But I find it plausible that I might well want to derive
from the same type I'm delegating to,
so not turning that possibility off seems like a plus for me. I have
no intention to write proxy iterators,
but I do think it quite likely that I'll use an operator-dot in types
other than what its motivation suggests.

--
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/CAFk2RUZW9sGqbQPVqWWk3C%3DYU_BsvLE_NkfPyX1G%2BxwRedHX1A%40mail.gmail.com.

.

On 29 June 2017 at 00:15, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> And if we don't get consensus for either of the smart-references
> proposals, life will go on.  Very much so.  I'd rather spend
> WG21 committee time on concepts than on smart references.


On that part I can easily grant your wish, because I have no plans to
discuss smart references
in Toronto.

--
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/CAFk2RUYUQatN_1qmPMmpE%2BGO7JOAJVQNy-AoCMKAFb%2BNwLKnaw%40mail.gmail.com.

.

--089e0822494c926f2505530bba1f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 28, 2017 at 11:27 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 28 June 2017 at 20:19, Nicol Bolas <jmckesson@gmail.com> wrote:
> > Base classes represent an "is-a" relationship. Why would you need to
> proxy yourself?
>
> That's a funny question. Fairly many proxies look like this:
>
> struct DaInterface
> {
>     virtual void mah_bucketz() =3D 0;
> };
>
> struct DaProxy : DaInterface
> {
>     DaInterface* proxy_target;
>     void mah_bucketz()
>     {
>         // preamble code
>         proxy_target->mah_bucketz();
>         // post-amble code
>     }
> };
>

This is a very interesting example!  However, I think you're right that
delegation can't be used for this purpose. I mean, my initial reaction was
to rewrite this code (using P0352 syntax for delegation) like this:

struct DaInterface {
    virtual void mah_bucketz() =3D 0;
};
struct DaReality {
    void mah_buckets() override { puts("welcome to reality"); }
};
struct DaProxy : using DaInterface {
    DaInterface *proxy_target;
    operator DaInterface&() { return proxy_target; }
    operator const DaInterface&() const { return proxy_target; }
};

However, I see the problem with this =E2=80=94 Because DaProxy does not
layout-inherit from DaInterface, DaProxy IS-NOT-A DaInterface; it does not
have a vptr. And therefore the following won't work:

void use(DaInterface *p) {
    p->mah_bucketz();  // access the virtual method
}
int main() {
    DaProxy x { new DaReality };
    use(&x);  // DOES NOT WORK! because x IS-NOT-A DaInterface at all
}

Furthermore, there is nowhere to plug in that "preamble code" and
"postamble code" that Ville wants in DaProxy.
And this is because {P0416, P0352} are mechanisms to delegate from a
certain (more or less dotted) *syntax* into the behaviors of some *existing=
*
class. It's not a mechanism for creating *new* behaviors out of whole
cloth. And "do this, but with a preamble" is a *new* behavior.

I think Ville has a cool problem here, and a realistic use-case. I just
don't see any suitably elegant way to tell the code-generator, "I want you
to give me a whole set of virtual methods just like my parent, but with
this preamble and this postamble."  It's kind of like the way the compiler
generates thunks around parent virtuals, but this is at a whole new level
that feels like it would need *lots* of new heavyweight syntax.

=E2=80=93Arthur

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CADvuK0KMkN7rMma%3Dh2kwiEhN2SDSug51zs5oDAuWMjkzb=
Jk4UQ%40mail.gmail.com.

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

<div dir=3D"ltr">On Wed, Jun 28, 2017 at 11:27 AM, Ville Voutilainen <span =
dir=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_b=
lank">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"gmail=
-">On 28 June 2017 at 20:19, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gm=
ail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; Base classes represent an &quot;is-a&quot; relationship. Why would you=
 need to proxy=C2=A0yourself?<br>
<br>
</span>That&#39;s a funny question. Fairly many proxies look like this:<br>
<br>
struct DaInterface<br>
{<br>
=C2=A0 =C2=A0 virtual void mah_bucketz() =3D 0;<br>
};<br>
<br>
struct DaProxy : DaInterface<br>
{<br>
=C2=A0 =C2=A0 DaInterface* proxy_target;<br>
=C2=A0 =C2=A0 void mah_bucketz()<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // preamble code<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy_target-&gt;mah_bucketz();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // post-amble code<br>
=C2=A0 =C2=A0 }<br>
};<br></blockquote><div><br></div><div>This is a very interesting example!=
=C2=A0 However, I think you&#39;re right that delegation can&#39;t be used =
for this purpose. I mean, my initial reaction was to rewrite this code (usi=
ng P0352 syntax for delegation) like this:</div><div><br></div><div>struct =
DaInterface {</div><div>=C2=A0 =C2=A0 virtual void mah_bucketz() =3D 0;</di=
v><div>};</div><div>struct DaReality {</div><div>=C2=A0 =C2=A0 void mah_buc=
kets() override { puts(&quot;welcome to reality&quot;); }</div><div>};</div=
><div>struct DaProxy : using DaInterface {</div><div>=C2=A0 =C2=A0 DaInterf=
ace *proxy_target;</div><div>=C2=A0 =C2=A0 operator DaInterface&amp;() { re=
turn proxy_target; }</div><div>=C2=A0 =C2=A0 operator const DaInterface&amp=
;() const { return proxy_target; }</div><div>};</div><div><br></div><div>Ho=
wever, I see the problem with this =E2=80=94 Because DaProxy does not layou=
t-inherit from DaInterface, DaProxy IS-NOT-A DaInterface; it does not have =
a vptr. And therefore the following won&#39;t work:</div><div><br></div><di=
v>void use(DaInterface *p) {</div><div>=C2=A0 =C2=A0 p-&gt;mah_bucketz(); =
=C2=A0// access the virtual method</div><div>}</div><div>int main() {</div>=
<div>=C2=A0 =C2=A0 DaProxy x { new DaReality };</div><div>=C2=A0 =C2=A0 use=
(&amp;x); =C2=A0// DOES NOT WORK! because x IS-NOT-A DaInterface at all</di=
v><div>}</div><div><br></div><div>Furthermore, there is nowhere to plug in =
that &quot;preamble code&quot; and &quot;postamble code&quot; that Ville wa=
nts in DaProxy.</div><div>And this is because {P0416, P0352} are mechanisms=
 to delegate from a certain (more or less dotted) <i>syntax</i> into the be=
haviors of some <i>existing</i> class. It&#39;s not a mechanism for creatin=
g <i>new</i> behaviors out of whole cloth. And &quot;do this, but with a pr=
eamble&quot; is a <i>new</i> behavior.</div><div><br></div><div>I think Vil=
le has a cool problem here, and a realistic use-case. I just don&#39;t see =
any suitably elegant way to tell the code-generator, &quot;I want you to gi=
ve me a whole set of virtual methods just like my parent, but with this pre=
amble and this postamble.&quot; =C2=A0It&#39;s kind of like the way the com=
piler generates thunks around parent virtuals, but this is at a whole new l=
evel that feels like it would need <i>lots</i> of new heavyweight syntax.</=
div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CADvuK0KMkN7rMma%3Dh2kwiEhN2SDSug51zs=
5oDAuWMjkzbJk4UQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KMkN7rMm=
a%3Dh2kwiEhN2SDSug51zs5oDAuWMjkzbJk4UQ%40mail.gmail.com</a>.<br />

--089e0822494c926f2505530bba1f--

.

On 29 June 2017 at 00:18, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> I think Ville has a cool problem here, and a realistic use-case. I just
> don't see any suitably elegant way to tell the code-generator, "I want you
> to give me a whole set of virtual methods just like my parent, but with this
> preamble and this postamble."  It's kind of like the way the compiler
> generates thunks around parent virtuals, but this is at a whole new level
> that feels like it would need lots of new heavyweight syntax.


There are reflection-related proposals that go into such directions.
One example of those is
this one: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf

I have had some discussions about the drafts of that proposal, and
pointed out that it can
do what operator-dot (or the conversion-delegation) can do. The
response to that was along the lines of "oh.. interesting". :)

I think I want a programmable call dispatch mechanism. With powerful
enough reflection, I can
get it. And I am not constrained by the hard-coded decisions that the
competing operator-dot proposals need to make.

--
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/CAFk2RUZ2b5mRxP2Mj%3DODghtPz1v_d75uvDs2-c2WUvow3EcESQ%40mail.gmail.com.

.

--Apple-Mail=_FE8DF8AC-1D6E-4AFC-BA10-3B475A26BA9A
Content-Type: text/plain; charset="UTF-8"

     (Pops head up from list-lurking.)  Reflection and virtual concepts, maybe?

Returning to lurking,
     Bryce Glover
     RandomDSdevel@gmail.com

--
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/5C25CEF9-8728-4D94-B4C3-2885B3BA8DC2%40gmail.com.

--Apple-Mail=_FE8DF8AC-1D6E-4AFC-BA10-3B475A26BA9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;" class=3D""><div class=3D""=
>&nbsp; &nbsp; &nbsp;(<i class=3D"">Pops head up from list-lurking.</i>) &n=
bsp;Reflection and virtual concepts, maybe? &nbsp;</div><br class=3D""><div=
 class=3D"">
<div style=3D"color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-w=
rap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-=
space;" class=3D""><div style=3D"color: rgb(0, 0, 0); letter-spacing: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-=
break: after-white-space;" class=3D""><div style=3D"color: rgb(0, 0, 0); le=
tter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; t=
ext-transform: none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div class=3D"">Re=
turning to lurking,&nbsp;</div><div class=3D"">&nbsp; &nbsp; &nbsp;Bryce Gl=
over</div><div class=3D"">&nbsp; &nbsp; &nbsp;<a href=3D"mailto:RandomDSdev=
el@gmail.com" class=3D"">RandomDSdevel@gmail.com</a></div></div></div></div=
></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5C25CEF9-8728-4D94-B4C3-2885B3BA8DC2%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5C25CEF9-8728-4D94-B4C3-2885B3BA8DC2%=
40gmail.com</a>.<br />

--Apple-Mail=_FE8DF8AC-1D6E-4AFC-BA10-3B475A26BA9A--

.

On Wed, Jun 28, 2017 at 4:15 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

<snip>

> And if we don't get consensus for either of the smart-references
> proposals, life will go on.  Very much so.  I'd rather spend
> WG21 committee time on concepts than on smart references.
>

+1

p.s. While there are reasonably coherent answers to most questions
raised in this thread about the delegate/adapter proposal that would
be close enough to some (and not so to others) to the principle of
least surprise for even some of the more complicated
examples/questions on this thread (using what most of us know about
name-lookup, const-and-value-category based overloading of implicit
object parameters, conversion operators and the new rules from the
proposal) - in the end it might just come down to taste and commitment
- and given that this appears to already be a divisive topic with
strong folks claiming conclusive opinions on either side - (I should
admit that though a co-author of the adapter proposal, I would
characterize my opinion as malleable - I cared enough to co-author a
respectful proposal that we thought could give rise to a compromise
that might increase consensus)  - but given the response, now I too
worry about embroiling the committee in an opinionated discussion that
could take chunks of time away from progress on far more influential
features (such as concepts) - but whether the committee is steered
into those waters is more Ville's burden to bear than mine ;)

p.s. If we really want true (compile-time or run-time) intercession or
aspects - I also remain convinced that neither of these would be the
best approach to solving those problems.

--
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/CABsSThoQzjni91MwvoooqyRV7jgj6an0F3ejayFMQ%2BuWpUE2%3DA%40mail.gmail.com.

.

------=_Part_5149_330335804.1499467432609
Content-Type: multipart/alternative;
 boundary="----=_Part_5150_994010836.1499467432610"

------=_Part_5150_994010836.1499467432610
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



>
>> struct DaInterface
>> {
>>     virtual void mah_bucketz() =3D 0;
>> };
>>
>> struct DaProxy : DaInterface
>> {
>>     DaInterface* proxy_target;
>>     void mah_bucketz()
>>     {
>>         // preamble code
>>         proxy_target->mah_bucketz();
>>         // post-amble code
>>     }
>> };
>>
>
> This is a very interesting example!  However, I think you're right that=
=20
> delegation can't be used for this purpose. I mean, my initial reaction wa=
s=20
> to rewrite this code (using P0352 syntax for delegation) like this:
>
> struct DaInterface {
>     virtual void mah_bucketz() =3D 0;
> };
> struct DaReality {
>     void mah_buckets() override { puts("welcome to reality"); }
> };
> struct DaProxy : using DaInterface {
>     DaInterface *proxy_target;
>     operator DaInterface&() { return proxy_target; }
>     operator const DaInterface&() const { return proxy_target; }
> };
>
> However, I see the problem with this =E2=80=94 Because DaProxy does not=
=20
> layout-inherit from DaInterface, DaProxy IS-NOT-A DaInterface; it does no=
t=20
> have a vptr. And therefore the following won't work:
>
> void use(DaInterface *p) {
>     p->mah_bucketz();  // access the virtual method
> }
> int main() {
>     DaProxy x { new DaReality };
>     use(&x);  // DOES NOT WORK! because x IS-NOT-A DaInterface at all
> }
>
As it stands this does not compile, but if you want your proxy to be more=
=20
transparent you could add an operator&() to it, returning the DaInterface*=
=20
it contains. I think the call by reference case may be more interesting:

void use(DaInterface& r) { r.mah_bucketz(); }

DaProxy x { new DaReality; }

use(x);

Nah, this obviously calls the conversion operator (even now).

It would be possible to allow overriding virtual methods from the using=20
base to get pre- and postamble code, creating a vtable where all=20
non-overridden methods are thunked with a function calling the operator=20
Base() and then the baseclass method (using virtual dispatch) but inside=20
the use(DaInterface&) function those overridden functions would not be=20
called anyway as the proxy has been dereffed already. This could be very=20
confusing if you forget what using bases are.

I don't think any of this invalidates the mechanism as such, but I think it=
=20
should be sold as a "rewrite rule" rather than a real inheritance. This=20
speaks against using the baseclass list for this purpose and instead for=20
annotation of the cast operator itself, such as by my previously suggested:

class DaProxy {
    operator DaInterface&() implicit;
}

Here the proxy obviously does not inherit the interface, but the word=20
implcit means that when using a DaProxy object conversions should be as-if=
=20
it was inheriting DaInterface (rewrite rule, sort of).

=20

>
> Furthermore, there is nowhere to plug in that "preamble code" and=20
> "postamble code" that Ville wants in DaProxy.
> And this is because {P0416, P0352} are mechanisms to delegate from a=20
> certain (more or less dotted) *syntax* into the behaviors of some=20
> *existing* class. It's not a mechanism for creating *new* behaviors out=
=20
> of whole cloth. And "do this, but with a preamble" is a *new* behavior.
>
> I think Ville has a cool problem here, and a realistic use-case. I just=
=20
> don't see any suitably elegant way to tell the code-generator, "I want yo=
u=20
> to give me a whole set of virtual methods just like my parent, but with=
=20
> this preamble and this postamble."  It's kind of like the way the compile=
r=20
> generates thunks around parent virtuals, but this is at a whole new level=
=20
> that feels like it would need *lots* of new heavyweight syntax.
>

I guess this is what P0707 could offer=20
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf)=20
together with the compile time reflection it relies on. The entire=20
operator.() problem could be solved by P0707 given the right detailed=20
design, I would guess. If not I think that detailed design would be flawed.
=20

>
> =E2=80=93Arthur
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/022a1821-009f-457a-b4dc-a5e2ba2a328d%40isocpp.or=
g.

------=_Part_5150_994010836.1499467432610
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<br><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=
 class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><br>
struct DaInterface<br>
{<br>
=C2=A0 =C2=A0 virtual void mah_bucketz() =3D 0;<br>
};<br>
<br>
struct DaProxy : DaInterface<br>
{<br>
=C2=A0 =C2=A0 DaInterface* proxy_target;<br>
=C2=A0 =C2=A0 void mah_bucketz()<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // preamble code<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proxy_target-&gt;mah_bucketz();<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // post-amble code<br>
=C2=A0 =C2=A0 }<br>
};<br></blockquote><div><br></div><div>This is a very interesting example!=
=C2=A0 However, I think you&#39;re right that delegation can&#39;t be used =
for this purpose. I mean, my initial reaction was to rewrite this code (usi=
ng P0352 syntax for delegation) like this:</div><div><br></div><div>struct =
DaInterface {</div><div>=C2=A0 =C2=A0 virtual void mah_bucketz() =3D 0;</di=
v><div>};</div><div>struct DaReality {</div><div>=C2=A0 =C2=A0 void mah_buc=
kets() override { puts(&quot;welcome to reality&quot;); }</div><div>};</div=
><div>struct DaProxy : using DaInterface {</div><div>=C2=A0 =C2=A0 DaInterf=
ace *proxy_target;</div><div>=C2=A0 =C2=A0 operator DaInterface&amp;() { re=
turn proxy_target; }</div><div>=C2=A0 =C2=A0 operator const DaInterface&amp=
;() const { return proxy_target; }</div><div>};</div><div><br></div><div>Ho=
wever, I see the problem with this =E2=80=94 Because DaProxy does not layou=
t-inherit from DaInterface, DaProxy IS-NOT-A DaInterface; it does not have =
a vptr. And therefore the following won&#39;t work:</div><div><br></div><di=
v>void use(DaInterface *p) {</div><div>=C2=A0 =C2=A0 p-&gt;mah_bucketz(); =
=C2=A0// access the virtual method</div><div>}</div><div>int main() {</div>=
<div>=C2=A0 =C2=A0 DaProxy x { new DaReality };</div><div>=C2=A0 =C2=A0 use=
(&amp;x); =C2=A0// DOES NOT WORK! because x IS-NOT-A DaInterface at all</di=
v><div>}</div></div></div></div></blockquote><div>As it stands this does no=
t compile, but if you want your proxy to be more transparent you could add =
an operator&amp;() to it, returning the DaInterface* it contains. I think t=
he call by reference case may be more interesting:</div><div><br></div><div=
>void use(DaInterface&amp; r) { r.mah_bucketz(); }</div><div><br></div><div=
>DaProxy x { new DaReality; }</div><div><br></div><div>use(x);</div><div><b=
r></div><div>Nah, this obviously calls the conversion operator (even now).<=
/div><div><br></div><div>It would be possible to allow overriding virtual m=
ethods from the using base to get pre- and postamble code, creating a vtabl=
e where all non-overridden methods are thunked with a function calling the =
operator Base() and then the baseclass method (using virtual dispatch) but =
inside the use(DaInterface&amp;) function those overridden functions would =
not be called anyway as the proxy has been dereffed already. This could be =
very confusing if you forget what using bases are.</div><div><br></div><div=
>I don&#39;t think any of this invalidates the mechanism as such, but I thi=
nk it should be sold as a &quot;rewrite rule&quot; rather than a real inher=
itance. This speaks against using the baseclass list for this purpose and i=
nstead for annotation of the cast operator itself, such as by my previously=
 suggested:</div><div><br></div><div>class DaProxy {</div><div>=C2=A0 =C2=
=A0 operator DaInterface&amp;() implicit;</div><div>}</div><div><br></div><=
div>Here the proxy obviously does not inherit the interface, but the word i=
mplcit means that when using a DaProxy object conversions should be as-if i=
t was inheriting DaInterface (rewrite rule, sort of).</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"lt=
r"><div><div class=3D"gmail_quote"><div><br></div><div>Furthermore, there i=
s nowhere to plug in that &quot;preamble code&quot; and &quot;postamble cod=
e&quot; that Ville wants in DaProxy.</div><div>And this is because {P0416, =
P0352} are mechanisms to delegate from a certain (more or less dotted) <i>s=
yntax</i> into the behaviors of some <i>existing</i> class. It&#39;s not a =
mechanism for creating <i>new</i> behaviors out of whole cloth. And &quot;d=
o this, but with a preamble&quot; is a <i>new</i> behavior.</div><div><br><=
/div><div>I think Ville has a cool problem here, and a realistic use-case. =
I just don&#39;t see any suitably elegant way to tell the code-generator, &=
quot;I want you to give me a whole set of virtual methods just like my pare=
nt, but with this preamble and this postamble.&quot; =C2=A0It&#39;s kind of=
 like the way the compiler generates thunks around parent virtuals, but thi=
s is at a whole new level that feels like it would need <i>lots</i> of new =
heavyweight syntax.</div></div></div></div></blockquote><div><br></div><div=
>I guess this is what P0707 could offer (http://www.open-std.org/jtc1/sc22/=
wg21/docs/papers/2017/p0707r0.pdf) together with the compile time reflectio=
n it relies on. The entire operator.() problem could be solved by P0707 giv=
en the right detailed design, I would guess. If not I think that detailed d=
esign would be flawed.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></=
div><div>=E2=80=93Arthur</div></div></div></div>
</blockquote>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/022a1821-009f-457a-b4dc-a5e2ba2a328d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/022a1821-009f-457a-b4dc-a5e2ba2a328d=
%40isocpp.org</a>.<br />

------=_Part_5150_994010836.1499467432610--

------=_Part_5149_330335804.1499467432609--

.

------=_Part_420_1320962935.1500550767007
Content-Type: multipart/alternative;
 boundary="----=_Part_421_1757973844.1500550767008"

------=_Part_421_1757973844.1500550767008
Content-Type: text/plain; charset="UTF-8"


On Saturday, 8 July 2017 00:43:52 UTC+2, Bengt Gustafsson wrote:

> class DaProxy {
>     operator DaInterface&() implicit;
> }
>
> Here the proxy obviously does not inherit the interface, but the word
> implcit means that when using a DaProxy object conversions should be as-if
> it was inheriting DaInterface (rewrite rule, sort of).
>

I experimented with such a concept a while back (I called them auto
conversions since implicit conversion is already a thing). I started with
the premise that "smart references" should behave exactly like regular
references as far as is possible. For example:

T v1;
ref<T> r1 = v1;
auto v2 = r1; // decltype(v2) is T
ref<auto> r2 = v1; // decltype(r2) is ref<T>
ref<auto> r3 = r1; // decltype(r3) is ref<T>

The problem is that it requires adding a whole bunch of new rules for type
deduction and conversion, which is definitely not a trivial matter. That
said, I think this would be the most promising approach because it more
accurately reflects how references behave, in that T& does not inherit from
T, but T& can convert to and from T (does the delegation proposal support
smart references to non-class types?)

However, while the feature would be useful for implementing "interface
adapters" such as propagate_const, I question whether it is really worth
introducing such additional complexity into the language in any of the
proposed forms. There are probably more important things to be working on.

--
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/44d938d3-df23-46a3-86d2-33c344bf86f4%40isocpp.org.

------=_Part_421_1757973844.1500550767008
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Saturday, 8 July 2017 00:43:52 UTC+2, Bengt Gustafs=
son  wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>class DaPr=
oxy {</div><div>=C2=A0 =C2=A0 operator DaInterface&amp;() implicit;</div><d=
iv>}</div><div><br></div><div>Here the proxy obviously does not inherit the=
 interface, but the word implcit means that when using a DaProxy object con=
versions should be as-if it was inheriting DaInterface (rewrite rule, sort =
of).</div></blockquote><div><br>I experimented with such a concept a while =
back (I called them <span style=3D"font-family: courier new,monospace;">aut=
o</span> conversions since implicit conversion is already a thing). I start=
ed with the premise that &quot;smart references&quot; should behave exactly=
 like regular references as far as is possible. For example:<br><br><div st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; overflow-wrap: break-word;" cla=
ss=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">T v1</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">ref</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> r1 </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 v1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> v2 </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> r1</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// decltype(v2) is T</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">ref</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">&lt;auto&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> r2 </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v1</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// decltype(r2) is ref&lt;T&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">ref</span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">&lt;auto&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> r3 </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> r1</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">// decltype(r3) is ref&lt;T&gt;</span></div></code></div=
><br>The problem is that it requires adding a whole bunch of new rules for =
type deduction and conversion, which is definitely not a trivial matter. Th=
at said, I think this would be the most promising approach because it more =
accurately reflects how references behave, in that <span style=3D"font-fami=
ly: courier new,monospace;">T&amp;</span> does not inherit from <span style=
=3D"font-family: courier new,monospace;">T</span>, but <span style=3D"font-=
family: courier new,monospace;">T&amp;</span> can convert to and from <span=
 style=3D"font-family: courier new,monospace;">T</span> (does the delegatio=
n proposal support smart references to non-class types?)<br><br>However, wh=
ile the feature would be useful for implementing &quot;interface adapters&q=
uot; such as <span style=3D"font-family: courier new,monospace;">propagate_=
const</span>, I question whether it is really worth introducing such additi=
onal complexity into the language in any of the proposed forms. There are p=
robably more important things to be working on.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/44d938d3-df23-46a3-86d2-33c344bf86f4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44d938d3-df23-46a3-86d2-33c344bf86f4=
%40isocpp.org</a>.<br />

------=_Part_421_1757973844.1500550767008--

------=_Part_420_1320962935.1500550767007--

.

------=_Part_1155_502668961.1500619635567
Content-Type: multipart/alternative;
 boundary="----=_Part_1156_1606846818.1500619635567"

------=_Part_1156_1606846818.1500619635567
Content-Type: text/plain; charset="UTF-8"



Den torsdag 20 juli 2017 kl. 13:39:27 UTC+2 skrev joseph....@gmail.com:
>
>
> On Saturday, 8 July 2017 00:43:52 UTC+2, Bengt Gustafsson wrote:
>
>> class DaProxy {
>>     operator DaInterface&() implicit;
>> }
>>
>> Here the proxy obviously does not inherit the interface, but the word
>> implcit means that when using a DaProxy object conversions should be as-if
>> it was inheriting DaInterface (rewrite rule, sort of).
>>
>
> I experimented with such a concept a while back (I called them auto
> conversions since implicit conversion is already a thing). I started with
> the premise that "smart references" should behave exactly like regular
> references as far as is possible. For example:
>
> T v1;
> ref<T> r1 = v1;
> auto v2 = r1; // decltype(v2) is T
> ref<auto> r2 = v1; // decltype(r2) is ref<T>
> ref<auto> r3 = r1; // decltype(r3) is ref<T>
>
> The problem is that it requires adding a whole bunch of new rules for type
> deduction and conversion, which is definitely not a trivial matter. That
> said, I think this would be the most promising approach because it more
> accurately reflects how references behave, in that T& does not inherit
> from T, but T& can convert to and from T (does the delegation proposal
> support smart references to non-class types?)
>

Avoiding having to write new rules is a primary reason to view this as
indirect inheritance, regardless of the syntax. Just like smart pointers
only mimic regular pointers to a certain level, smart references can (and
should) mimic regular references only to a certain level. Basically what we
want to do is to put a dot after the name of a smart reference and refer to
its members and methods, but it could also be of interest to let conversion
to T& be as cheap as if it was a base class.

If the syntax is related to a cast operator there is no reason to exclude
basic types, but as the main purpose is the dot and basic types don't have
members or methods this may not be all that important (compared to what we
already get with the current cast operators). The only visible difference I
can think of would be in a call to a function which takes an object of a
type with a non-explicit constructor from the basic type, where this would
currently not compile as there would be two user defined conversions
chained:

class A {
    A(int) {}
};

class ref {
    operator int() { return 0; }
};

void fun(A a);

fun(1);    // works

ref x;

fun(x);   // Error: Can't chain cast operator and constructor-conversion.


Being able to call fun with x does not seem like a pressing need (and
non-explicit one parameter ctors are discouraged anyway).

For user defined types there is another biggie which is the rules for
overloading of methods, which is where the analogy with inheritance is
important: If a method or member can be found in the subclass (or smart
reference) it is selected, but if none is found the baseclass (or refered
object) is consulted. The good thing about viewing smart references as
inheriting is that the rules for these situations are already in place and
well known for the inheritance case, apart from being logical and suitable
for a smart reference.

One thing that has not been covered in this thread is assignment operators.
However, it seems that the non-inheritance of assignment operators from
base classes rule is exactly what we want for smart references too, so
there is no additional rules to write for this either. Some more musing
over the implications of this may be needed though, to see if there are
some non-obvious cases where the inheritance rules may not be suitable, for
instance for move or for the other assignment operators like operator+=().


> However, while the feature would be useful for implementing "interface
> adapters" such as propagate_const, I question whether it is really worth
> introducing such additional complexity into the language in any of the
> proposed forms. There are probably more important things to be working on.
>

In the process of C++ standardization it is up to those who do the work to
define the priorities. If I or someone else are interested (as were the
authors of P0352) then it is obviously interesting enough. Given the large
interest there has been in operator.() proposals I don't think this is a
minor thing.

Finally a word about syntax. I'm personally very uncertain of which I like
better between an annotated inheritance combined with a regular cast
operator or an annotated cast operator and nothing in the base class list.
One new idea I got was to call this _explicit_ inheritance, which would
mean (of course) that the current type of inheritance is implicit, in the
sense that the location of the base class object is implicitly known, while
for an explicit inheritance the implementor of the subclass must provide a
means to convert the object to its baseclass using a cast operator. The
drawback with this idea is that putting _explicit_ on the cast operator
itself is already allowed and has another meaning. Other than that I think
it is easier to understand than _using_ in the base class list.

--
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/317d9366-917a-421d-9759-df4f0b7c6c01%40isocpp.org.

------=_Part_1156_1606846818.1500619635567
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Den torsdag 20 juli 2017 kl. 13:39:27 UTC+2 skrev =
joseph....@gmail.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br>On Saturday, 8 July 2017 00:43:52 UTC+2, Bengt Gustafsson  wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div>class DaProxy {</div><d=
iv>=C2=A0 =C2=A0 operator DaInterface&amp;() implicit;</div><div>}</div><di=
v><br></div><div>Here the proxy obviously does not inherit the interface, b=
ut the word implcit means that when using a DaProxy object conversions shou=
ld be as-if it was inheriting DaInterface (rewrite rule, sort of).</div></b=
lockquote><div><br>I experimented with such a concept a while back (I calle=
d them <span style=3D"font-family:courier new,monospace">auto</span> conver=
sions since implicit conversion is already a thing). I started with the pre=
mise that &quot;smart references&quot; should behave exactly like regular r=
eferences as far as is possible. For example:<br><br><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px"><code><div><span style=3D"color:#000">T v1</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#008">ref</span><span style=3D"color:#660">&lt;</span><span styl=
e=3D"color:#000">T</span><span style=3D"color:#660">&gt;</span><span style=
=3D"color:#000"> r1 </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> v1</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br></span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> v2 </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> r1</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"> </span><span style=3D"color:#800">// decltype(v2) is T</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#008">ref</span>=
<span style=3D"color:#080">&lt;auto&gt;</span><span style=3D"color:#000"> r=
2 </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> v=
1</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#800">// decltype(r2) is ref&lt;T&gt;</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#008">ref</span><span s=
tyle=3D"color:#080">&lt;auto&gt;</span><span style=3D"color:#000"> r3 </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> r1</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#800">// decltype(r3) is ref&lt;T&gt;</span></div></code><=
/div><br>The problem is that it requires adding a whole bunch of new rules =
for type deduction and conversion, which is definitely not a trivial matter=
.. That said, I think this would be the most promising approach because it m=
ore accurately reflects how references behave, in that <span style=3D"font-=
family:courier new,monospace">T&amp;</span> does not inherit from <span sty=
le=3D"font-family:courier new,monospace">T</span>, but <span style=3D"font-=
family:courier new,monospace">T&amp;</span> can convert to and from <span s=
tyle=3D"font-family:courier new,monospace">T</span> (does the delegation pr=
oposal support smart references to non-class types?)<br></div></div></block=
quote><div>=C2=A0</div><div>Avoiding having to write new rules is a primary=
 reason to view this as indirect inheritance, regardless of the syntax. Jus=
t like smart pointers only mimic regular pointers to a certain level, smart=
 references can (and should) mimic regular references only to a certain lev=
el. Basically what we want to do is to put a dot after the name of a smart =
reference and refer to its members and methods, but it could also be of int=
erest to let conversion to T&amp; be as cheap as if it was a base class.</d=
iv><div><br></div><div>If the syntax is related to a cast operator there is=
 no reason to exclude basic types, but as the main purpose is the dot and b=
asic types don&#39;t have members or methods this may not be all that impor=
tant (compared to what we already get with the current cast operators). The=
 only visible difference I can think of would be in a call to a function wh=
ich takes an object of a type with a non-explicit constructor from the basi=
c type, where this would currently not compile as there would be two user d=
efined conversions chained:</div><div><br></div><div>class A {</div><div>=
=C2=A0 =C2=A0 A(int) {}</div><div>};</div><div><br></div><div>class ref {</=
div><div>=C2=A0 =C2=A0 operator int() { return 0; }</div><div>};</div><div>=
<br></div><div>void fun(A a);</div><div><br></div><div>fun(1); =C2=A0 =C2=
=A0// works</div><div><br></div><div>ref x;</div><div><br></div><div>fun(x)=
; =C2=A0 // Error: Can&#39;t chain cast operator and constructor-conversion=
..</div><div><br></div><div><br></div><div>Being able to call fun with x doe=
s not seem like a pressing need (and non-explicit one parameter ctors are d=
iscouraged anyway).</div><div><br></div><div>For user defined types there i=
s another biggie which is the rules for overloading of methods, which is wh=
ere the analogy with inheritance is important: If a method or member can be=
 found in the subclass (or smart reference) it is selected, but if none is =
found the baseclass (or refered object) is consulted. The good thing about =
viewing smart references as inheriting is that the rules for these situatio=
ns are already in place and well known for the inheritance case, apart from=
 being logical and suitable for a smart reference.</div><div><br></div><div=
>One thing that has not been covered in this thread is assignment operators=
.. However, it seems that the non-inheritance of assignment operators from b=
ase classes rule is exactly what we want for smart references too, so there=
 is no additional rules to write for this either. Some more musing over the=
 implications of this may be needed though, to see if there are some non-ob=
vious cases where the inheritance rules may not be suitable, for instance f=
or move or for the other assignment operators like operator+=3D().</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><br>However, while the feature would be useful for implementing &quot;i=
nterface adapters&quot; such as <span style=3D"font-family:courier new,mono=
space">propagate_const</span>, I question whether it is really worth introd=
ucing such additional complexity into the language in any of the proposed f=
orms. There are probably more important things to be working on.<br></div><=
/div></blockquote><div><br></div><div>In the process of C++ standardization=
 it is up to those who do the work to define the priorities. If I or someon=
e else are interested (as were the authors of P0352) then it is obviously i=
nteresting enough. Given the large interest there has been in operator.() p=
roposals I don&#39;t think this is a minor thing.</div><div><br></div><div>=
Finally a word about syntax. I&#39;m personally very uncertain of which I l=
ike better between an annotated inheritance combined with a regular cast op=
erator or an annotated cast operator and nothing in the base class list. On=
e new idea I got was to call this _explicit_ inheritance, which would mean =
(of course) that the current type of inheritance is implicit, in the sense =
that the location of the base class object is implicitly known, while for a=
n explicit inheritance the implementor of the subclass must provide a means=
 to convert the object to its baseclass using a cast operator. The drawback=
 with this idea is that putting _explicit_ on the cast operator itself is a=
lready allowed and has another meaning. Other than that I think it is easie=
r to understand than _using_ in the base class list.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/317d9366-917a-421d-9759-df4f0b7c6c01%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/317d9366-917a-421d-9759-df4f0b7c6c01=
%40isocpp.org</a>.<br />

------=_Part_1156_1606846818.1500619635567--

------=_Part_1155_502668961.1500619635567--

.