Topic: Allow use of "->" when operator* presents
Author: junekey91@gmail.com
Date: Sat, 28 Jul 2018 14:56:18 -0700 (PDT)
Raw View
------=_Part_7367_984307169.1532814978131
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
The main motivation is that the language rule requires us to (eventually) r=
eturn raw pointers in operator->. I want to argue that this language rule i=
s problematic in at least two cases:
1. move iterator
The semantics of move iterators is that when dereferenced, the results are =
rvalue references. This just cannot be achieved with operator->, because th=
ere is no such thing as "rvalue pointer." By allowing to interpret "x->m" a=
s an alias of "(*x).m" if operator-> is not overloaded while operator* is o=
verloaded, we can achieve the move semantics with operator->.
First of all, perhaps some people might consider that getting rvalues from =
operator-> is weird, but to some other people (including myself), the fact =
that operator-> may turn something, move iterators that is meant to produce=
rvalues, to actually produce lvalues seem to be wrong.
There may be use-cases where operator* does not mean pointer dereferencing =
(or more generally, obtaining values or references stored somewhere), and f=
or those cases this proposed change might cause a problem. However, at leas=
t this is not a breaking change: if operator-> were overloaded together, th=
ere is no change ever, and if not, also there should be no place in existin=
g codes that are affected.
2. proxy iterators
Since operator-> requires us to return (eventually) raw pointers, we should=
have a real object somewhere in order to support this operator. This is at=
least (in some extent) doable in contrast to the move iterator case: retur=
n a proxy object that contains the proxy object returned by the operator*. =
This "proxy wrapper of proxy" then provides operator-> that returns the raw=
pointer into the contained proxy object. However, doing this just for the =
sake of supporting operator-> seems like an unnecessary overhead. Furthermo=
re, again this may break lvalue/rvalue-ness of the returned object, because=
in this way the (contained) proxy object is always obtained as an lvalue, =
which should have been obtained as a prvalue if operator* were used instead=
.. This would be less problematic than the case of move iterators, though.
Many users might expect "x->m" as a shortcut of "(*x).m" when both expressi=
ons are valid, but by no good reason the expectation is enforced to be brok=
en in these cases. By allowing this aliasing when operator-> is not overloa=
ded, this problem can be solved.
How do you think about it?
--=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/53f13047-62e7-4b31-ab7d-f3134e15eb08%40isocpp.or=
g.
------=_Part_7367_984307169.1532814978131--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 28 Jul 2018 22:12:54 -0700 (PDT)
Raw View
------=_Part_1560_851785953.1532841174290
Content-Type: multipart/alternative;
boundary="----=_Part_1561_923636987.1532841174290"
------=_Part_1561_923636987.1532841174290
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 28, 2018 at 5:56:18 PM UTC-4, june...@gmail.com wrote:
>
> The main motivation is that the language rule requires us to (eventually)
> return raw pointers in operator->.
There's another motivation: Concepts and `operator->` don't mix.
The current iterators in the Range TS/C++20 don't require `operator->`. One
of the reasons for this is that it's actually very hard to specify that
behavior via an expression. After all, `->` has to be followed by a member
name, and what if a template type doesn't have members? Overall, there's
not a simple way to check that `operator->` exists. By contrast, it's easy
to have `{*it} -> some_type;` in a requires clause.
Of course, we can still have our iterators provide an `operator->`. And
since there is no concept checking of implementations, the implementation
of a function that takes a Range TS iterator can still invoke `operator->`,
which will work with the existing iterators.
If we just say that we can synthesize an `operator->` if `operator*`
exists, then we don't have a problem. Concepts can just require `operator*`
using appropriate requirements, and the behavior of any usage of `->` is
expected to conform to the return value from `operator*`. The
implementation of a concept can use `->` when it is appropriate, and
everyone is happy.
--
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/2a326be3-4a3d-466e-819f-56dbac65b620%40isocpp.org.
------=_Part_1561_923636987.1532841174290
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 28, 2018 at 5:56:18 PM UTC-4, june...@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The main motivat=
ion is that the language rule requires us to (eventually) return raw pointe=
rs in operator->.</blockquote><div><br></div><div>There's another mo=
tivation: Concepts and `operator->` don't mix.</div><div><br></div><=
div>The current iterators in the Range TS/C++20 don't require `operator=
->`. One of the reasons for this is that it's actually very hard to =
specify that behavior via an expression. After all, `->` has to be follo=
wed by a member name, and what if a template type doesn't have members?=
Overall, there's not a simple way to check that `operator->` exists=
.. By contrast, it's easy to have `{*it} -> some_type;` in a requires=
clause.<br></div><div><br></div><div>Of course, we can still have our iter=
ators provide an `operator->`. And since there is no concept checking of=
implementations, the implementation of a function that takes a Range TS it=
erator can still invoke `operator->`, which will work with the existing =
iterators.</div><div><br></div><div>If we just say that we can synthesize a=
n `operator->` if `operator*` exists, then we don't have a problem. =
Concepts can just require `operator*` using appropriate requirements, and t=
he behavior of any usage of `->` is expected to conform to the return va=
lue from `operator*`. The implementation of a concept can use `->` when =
it is appropriate, and everyone is happy.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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/2a326be3-4a3d-466e-819f-56dbac65b620%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a326be3-4a3d-466e-819f-56dbac65b620=
%40isocpp.org</a>.<br />
------=_Part_1561_923636987.1532841174290--
------=_Part_1560_851785953.1532841174290--
.
Author: junekey91@gmail.com
Date: Mon, 30 Jul 2018 23:58:00 -0700 (PDT)
Raw View
------=_Part_11235_521442650.1533020281031
Content-Type: multipart/alternative;
boundary="----=_Part_11236_213479347.1533020281031"
------=_Part_11236_213479347.1533020281031
Content-Type: text/plain; charset="UTF-8"
Thank you for pointing out that!
But honestly I don't understand the issue correctly, so I want you to
elaborate more.
Why can't we just analyze something like decltype(it.operator->)?
Chaining of operator-> will make it harder to properly discover the
"actual" decltype, but that's certainly possible.
After reading Eric Niebler's blog posts on proxy iterators,
I expect things might be (very) complicated to properly support proxies,
but I can't figure out how exactly that can happen.
(For example, what's the problem of just comparing the return type of
operator* with the "actual" decltype of it.operator->?)
Also, I think "not saying anything about operator->" will not magically
guarantee things we normally expect about operator->,
because it is still possible that operator-> is overloaded. So in order to
provide proper guarantees,
it is still needed to check possible relations between operator* and
operator->, so the problem you pointed out may arise again.
However, I absolutely agree that Concepts can take advantage if the
proposed change on operator-> is accepted.
On Sunday, July 29, 2018 at 2:12:54 PM UTC+9, Nicol Bolas wrote:
>
> On Saturday, July 28, 2018 at 5:56:18 PM UTC-4, june...@gmail.com wrote:
>>
>> The main motivation is that the language rule requires us to (eventually)
>> return raw pointers in operator->.
>
>
> There's another motivation: Concepts and `operator->` don't mix.
>
> The current iterators in the Range TS/C++20 don't require `operator->`.
> One of the reasons for this is that it's actually very hard to specify that
> behavior via an expression. After all, `->` has to be followed by a member
> name, and what if a template type doesn't have members? Overall, there's
> not a simple way to check that `operator->` exists. By contrast, it's easy
> to have `{*it} -> some_type;` in a requires clause.
>
> Of course, we can still have our iterators provide an `operator->`. And
> since there is no concept checking of implementations, the implementation
> of a function that takes a Range TS iterator can still invoke `operator->`,
> which will work with the existing iterators.
>
> If we just say that we can synthesize an `operator->` if `operator*`
> exists, then we don't have a problem. Concepts can just require `operator*`
> using appropriate requirements, and the behavior of any usage of `->` is
> expected to conform to the return value from `operator*`. The
> implementation of a concept can use `->` when it is appropriate, and
> everyone is happy.
>
--
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/a572f176-5201-4f13-a890-18ea4185bf91%40isocpp.org.
------=_Part_11236_213479347.1533020281031
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thank you for pointing out that!</div><div><br></div>=
<div>But honestly I don't understand the issue correctly, so I want you=
to elaborate more.</div><div>Why can't we just analyze something like =
decltype(it.operator->)?</div><div>Chaining of operator-> will make i=
t harder to properly discover the "actual" decltype, but that'=
;s certainly possible.</div><div><br></div><div>After reading Eric Niebler&=
#39;s blog posts on proxy iterators,</div><div>I expect things might be (ve=
ry) complicated to properly support proxies, but I can't figure out how=
exactly that can happen.</div><div>(For example, what's the problem of=
just comparing the return type of operator* with the "actual" de=
cltype of it.operator->?)</div><div><br></div><div>Also, I think "n=
ot saying anything about operator->" will not magically guarantee t=
hings we normally expect about operator->,<br></div><div>because it is s=
till possible that operator-> is overloaded. So in order to provide prop=
er guarantees,</div><div>it is still needed to check possible relations bet=
ween operator* and operator->, so the problem you pointed out may arise =
again.</div><div><br></div><div>However, I absolutely agree that Concepts c=
an take advantage if the proposed change on operator-> is accepted.<br><=
/div><div><br></div><br><br>On Sunday, July 29, 2018 at 2:12:54 PM UTC+9, N=
icol Bolas wrote:<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">On Saturday, July 28, 2018 at 5:56:18 PM UTC-4, <a>june...@gmail.com</a=
> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">The main motivation is that=
the language rule requires us to (eventually) return raw pointers in opera=
tor->.</blockquote><div><br></div><div>There's another motivation: C=
oncepts and `operator->` don't mix.</div><div><br></div><div>The cur=
rent iterators in the Range TS/C++20 don't require `operator->`. One=
of the reasons for this is that it's actually very hard to specify tha=
t behavior via an expression. After all, `->` has to be followed by a me=
mber name, and what if a template type doesn't have members? Overall, t=
here's not a simple way to check that `operator->` exists. By contra=
st, it's easy to have `{*it} -> some_type;` in a requires clause.<br=
></div><div><br></div><div>Of course, we can still have our iterators provi=
de an `operator->`. And since there is no concept checking of implementa=
tions, the implementation of a function that takes a Range TS iterator can =
still invoke `operator->`, which will work with the existing iterators.<=
/div><div><br></div><div>If we just say that we can synthesize an `operator=
->` if `operator*` exists, then we don't have a problem. Concepts ca=
n just require `operator*` using appropriate requirements, and the behavior=
of any usage of `->` is expected to conform to the return value from `o=
perator*`. The implementation of a concept can use `->` when it is appro=
priate, and everyone is happy.<br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a572f176-5201-4f13-a890-18ea4185bf91%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a572f176-5201-4f13-a890-18ea4185bf91=
%40isocpp.org</a>.<br />
------=_Part_11236_213479347.1533020281031--
------=_Part_11235_521442650.1533020281031--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Tue, 31 Jul 2018 23:35:29 -0700 (PDT)
Raw View
------=_Part_12003_244940908.1533105329330
Content-Type: multipart/alternative;
boundary="----=_Part_12004_1062958564.1533105329330"
------=_Part_12004_1062958564.1533105329330
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno marted=C3=AC 31 luglio 2018 08:58:01 UTC+2, june...@gmail.com ha=
=20
scritto:
>
>
> Also, I think "not saying anything about operator->" will not magically=
=20
> guarantee things we normally expect about operator->,
> because it is still possible that operator-> is overloaded. So in order t=
o=20
> provide proper guarantees,
> it is still needed to check possible relations between operator* and=20
> operator->, so the problem you pointed out may arise again.
>
What about providing some opt-in syntax like
auto operator->() =3D default;
?
--=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/17350bb9-f223-48b5-9d64-70173325e678%40isocpp.or=
g.
------=_Part_12004_1062958564.1533105329330
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno marted=C3=AC 31 luglio 2018 08:58:01 UTC+2, june=
....@gmail.com ha scritto:<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"><br><div>Also, I think "not saying anything about operator=
->" will not magically guarantee things we normally expect about op=
erator->,<br></div><div>because it is still possible that operator-> =
is overloaded. So in order to provide proper guarantees,</div><div>it is st=
ill needed to check possible relations between operator* and operator->,=
so the problem you pointed out may arise again.</div></div></blockquote><d=
iv><br></div><div>What about providing some opt-in syntax like</div><div><b=
r></div><div>=C2=A0=C2=A0 auto operator->() =3D default;</div><div><br><=
/div><div>?<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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/17350bb9-f223-48b5-9d64-70173325e678%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/17350bb9-f223-48b5-9d64-70173325e678=
%40isocpp.org</a>.<br />
------=_Part_12004_1062958564.1533105329330--
------=_Part_12003_244940908.1533105329330--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 1 Aug 2018 00:08:27 -0700 (PDT)
Raw View
------=_Part_11865_1174745206.1533107307530
Content-Type: multipart/alternative;
boundary="----=_Part_11866_2094005365.1533107307531"
------=_Part_11866_2094005365.1533107307531
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=C3=AC 1 agosto 2018 08:35:29 UTC+2, Alberto Barbati ha=
=20
scritto:
>
> Il giorno marted=C3=AC 31 luglio 2018 08:58:01 UTC+2, june...@gmail.com h=
a=20
> scritto:
>>
>>
>> Also, I think "not saying anything about operator->" will not magically=
=20
>> guarantee things we normally expect about operator->,
>> because it is still possible that operator-> is overloaded. So in order=
=20
>> to provide proper guarantees,
>> it is still needed to check possible relations between operator* and=20
>> operator->, so the problem you pointed out may arise again.
>>
>
> What about providing some opt-in syntax like
>
> auto operator->() =3D default;
>
Or, better, we could allow operator->() to return either a pointer or a=20
reference and then interpret x->m as (x.operator->())->m or=20
(x.operator->()).m respectively.
--=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/238e09a4-3978-417d-9ed8-1f59d9e3bccb%40isocpp.or=
g.
------=_Part_11866_2094005365.1533107307531
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno mercoled=C3=AC 1 agosto 2018 08:35:29 UTC+2, Alb=
erto Barbati ha scritto:<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">Il giorno marted=C3=AC 31 luglio 2018 08:58:01 UTC+2, <a>june...=
@gmail.com</a> ha scritto:<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"><br><div>Also, I think "not saying anything about operator-&g=
t;" will not magically guarantee things we normally expect about opera=
tor->,<br></div><div>because it is still possible that operator-> is =
overloaded. So in order to provide proper guarantees,</div><div>it is still=
needed to check possible relations between operator* and operator->, so=
the problem you pointed out may arise again.</div></div></blockquote><div>=
<br></div><div>What about providing some opt-in syntax like</div><div><br><=
/div><div>=C2=A0=C2=A0 auto operator->() =3D default;</div></div></block=
quote><div><br></div><div>Or, better, we could allow operator->() to ret=
urn either a pointer or a reference and then interpret x->m as (x.operat=
or->())->m or (x.operator->()).m respectively.</div><div><br></div=
></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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/238e09a4-3978-417d-9ed8-1f59d9e3bccb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/238e09a4-3978-417d-9ed8-1f59d9e3bccb=
%40isocpp.org</a>.<br />
------=_Part_11866_2094005365.1533107307531--
------=_Part_11865_1174745206.1533107307530--
.
Author: junekey91@gmail.com
Date: Wed, 1 Aug 2018 01:39:45 -0700 (PDT)
Raw View
------=_Part_12457_1978032428.1533112786086
Content-Type: multipart/alternative;
boundary="----=_Part_12458_1013542323.1533112786086"
------=_Part_12458_1013542323.1533112786086
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Actually, I've considered that (returning references). But can't that may=
=20
break existing codes?
For example, what if someone's operator-> returns a reference to=20
pointer-like subobject?
If that pointer-like subobject is something like std::unique_ptr, we really=
=20
can't return by value,
so I expect those situations are indeed not very rare.
About opt-in syntax:
I like it. Perhaps we need to discuss about opt-in (=3Ddefault) vs opt-out=
=20
(=3Ddelete)?
On Wednesday, August 1, 2018 at 4:08:27 PM UTC+9, Alberto Barbati wrote:
>
> Il giorno mercoled=C3=AC 1 agosto 2018 08:35:29 UTC+2, Alberto Barbati ha=
=20
> scritto:
>>
>> Il giorno marted=C3=AC 31 luglio 2018 08:58:01 UTC+2, june...@gmail.com =
ha=20
>> scritto:
>>>
>>>
>>> Also, I think "not saying anything about operator->" will not magically=
=20
>>> guarantee things we normally expect about operator->,
>>> because it is still possible that operator-> is overloaded. So in order=
=20
>>> to provide proper guarantees,
>>> it is still needed to check possible relations between operator* and=20
>>> operator->, so the problem you pointed out may arise again.
>>>
>>
>> What about providing some opt-in syntax like
>>
>> auto operator->() =3D default;
>>
>
> Or, better, we could allow operator->() to return either a pointer or a=
=20
> reference and then interpret x->m as (x.operator->())->m or=20
> (x.operator->()).m respectively.
>
>
--=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/6d6c6199-44b5-4eff-93b1-4f878736972a%40isocpp.or=
g.
------=_Part_12458_1013542323.1533112786086
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Actually, I've considered that (returning referen=
ces). But can't that may break existing codes?</div><div>For example, w=
hat if someone's operator-> returns a reference to pointer-like subo=
bject?</div><div>If that pointer-like subobject is something like std::uniq=
ue_ptr, we really can't return by value,</div><div>so I expect those si=
tuations are indeed not very rare.</div><div><br></div><div>About opt-in sy=
ntax:</div><div>I like it. Perhaps we need to discuss about opt-in (=3Ddefa=
ult) vs opt-out (=3Ddelete)?</div><div><br></div><br><br>On Wednesday, Augu=
st 1, 2018 at 4:08:27 PM UTC+9, Alberto Barbati wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr">Il giorno mercoled=C3=AC 1 agosto =
2018 08:35:29 UTC+2, Alberto Barbati ha scritto:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">Il giorno marted=C3=AC 31 luglio 2018 08:58:0=
1 UTC+2, <a>june...@gmail.com</a> ha scritto:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><div>Also, I think "not saying anything=
about operator->" will not magically guarantee things we normally =
expect about operator->,<br></div><div>because it is still possible that=
operator-> is overloaded. So in order to provide proper guarantees,</di=
v><div>it is still needed to check possible relations between operator* and=
operator->, so the problem you pointed out may arise again.</div></div>=
</blockquote><div><br></div><div>What about providing some opt-in syntax li=
ke</div><div><br></div><div>=C2=A0=C2=A0 auto operator->() =3D default;<=
/div></div></blockquote><div><br></div><div>Or, better, we could allow oper=
ator->() to return either a pointer or a reference and then interpret x-=
>m as (x.operator->())->m or (x.operator->()).m respectively.</=
div><div><br></div></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6d6c6199-44b5-4eff-93b1-4f878736972a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6d6c6199-44b5-4eff-93b1-4f878736972a=
%40isocpp.org</a>.<br />
------=_Part_12458_1013542323.1533112786086--
------=_Part_12457_1978032428.1533112786086--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 1 Aug 2018 02:04:42 -0700 (PDT)
Raw View
------=_Part_11857_1108094788.1533114282490
Content-Type: multipart/alternative;
boundary="----=_Part_11858_651948878.1533114282490"
------=_Part_11858_651948878.1533114282490
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=C3=AC 1 agosto 2018 10:39:46 UTC+2, june...@gmail.com ha=
=20
scritto:
>
> Actually, I've considered that (returning references). But can't that may=
=20
> break existing codes?
> For example, what if someone's operator-> returns a reference to=20
> pointer-like subobject?
> If that pointer-like subobject is something like std::unique_ptr, we=20
> really can't return by value,
> so I expect those situations are indeed not very rare.
>
You are correct. Changing the interpretation of x->m according to the type=
=20
returned by operator-> is a no-go, since it may break existing code. I=20
realized that the specification deliberately allow "chaining" operator->,=
=20
that is it can return an object that in turn implements operator->=20
(returning an std::unique_ptr is precisely such a case).
=20
>
> About opt-in syntax:
> I like it. Perhaps we need to discuss about opt-in (=3Ddefault) vs opt-ou=
t=20
> (=3Ddelete)?
>
I'm starting to believe the best course of action could be this: if there's=
=20
no operator-> or if it is defaulted, then the expression x->m is always=20
interpreted as (*x).m.
This has the following advantages:
1) It's backward compatible. Expressions that were previously well-formed=
=20
do not change meaning. Expressions that were previously ill-formed may now=
=20
be well-formed.
2) you can opt-out from the interpretation (if you so desire) by either=20
providing a user-defined operator-> or declaring it as deleted
3) you can have both the synthesized operator *and* the user-provided=20
operator, since the two may overload, for example:
T* operator->();
auto operator->() const =3D default;
or
auto operator->() & =3D delete;
auto operator->() && =3D default;
Having the synthesized operator by default if no operator-> is found just=
=20
seems the right thing to do, but I'm not adamant about that.
A.
--=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/44f7d9e8-25a7-4cd2-8985-11ab312ef37f%40isocpp.or=
g.
------=_Part_11858_651948878.1533114282490
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>Il giorno mercoled=C3=AC 1 agosto 2018 10:39:46 UTC+2,=
june...@gmail.com ha scritto:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>Actually, I've considered that (returning referen=
ces). But can't that may break existing codes?</div><div>For example, w=
hat if someone's operator-> returns a reference to pointer-like subo=
bject?</div><div>If that pointer-like subobject is something like std::uniq=
ue_ptr, we really can't return by value,</div><div>so I expect those si=
tuations are indeed not very rare.</div></div></blockquote><div><br></div><=
div>You are correct. Changing the interpretation of x->m according to th=
e type returned by operator-> is a no-go, since it may break existing co=
de. I realized that the specification deliberately allow "chaining&quo=
t; operator->, that is it can return an object that in turn implements o=
perator-> (returning an std::unique_ptr is precisely such a case).<br></=
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><br></div><div>About opt-in syntax:</div><div>I like it. Perh=
aps we need to discuss about opt-in (=3Ddefault) vs opt-out (=3Ddelete)?</d=
iv></div></blockquote><div><br></div><div></div><div>I'm starting to be=
lieve the best course of action could be this: if there's no operator-&=
gt; or if it is defaulted, then the expression x->m is always interprete=
d as (*x).m.</div><div><br></div><div>This has the following advantages:<br=
></div><div><br></div><div>1) It's backward compatible. Expressions th=
at were previously well-formed do not change meaning. Expressions that were=
previously ill-formed may now be well-formed.</div><div><br></div><div>2) =
you can opt-out from the interpretation (if you so desire) by either provid=
ing a user-defined operator-> or declaring it as deleted</div><div><br><=
/div><div>3) you can have both the synthesized operator *and* the user-prov=
ided operator, since the two may overload, for example:<br></div><div><br><=
/div><div>=C2=A0=C2=A0=C2=A0 T* operator->();</div><div>=C2=A0=C2=A0=C2=
=A0 auto operator->() const =3D default;</div><div><br></div><div>or</di=
v><div><br></div><div>=C2=A0=C2=A0 auto operator->() & =3D delete;<b=
r></div><div>=C2=A0=C2=A0 auto operator->() && =3D default;</div=
><div><br></div><div>Having the synthesized operator by default if no opera=
tor-> is found just seems the right thing to do, but I'm not adamant=
about that.<br></div><div><br></div><div>A.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"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/44f7d9e8-25a7-4cd2-8985-11ab312ef37f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/44f7d9e8-25a7-4cd2-8985-11ab312ef37f=
%40isocpp.org</a>.<br />
------=_Part_11858_651948878.1533114282490--
------=_Part_11857_1108094788.1533114282490--
.
Author: junekey91@gmail.com
Date: Wed, 1 Aug 2018 05:40:19 -0700 (PDT)
Raw View
------=_Part_12209_2081723181.1533127219493
Content-Type: multipart/alternative;
boundary="----=_Part_12210_24417304.1533127219493"
------=_Part_12210_24417304.1533127219493
Content-Type: text/plain; charset="UTF-8"
In my opinion, multiple overloads, defaulting, deleting altogether seem to
needlessly complicate the things.
What if defaulted/deleted operator-> doesn't match cv-and-ref qualifiers of
operator*?
What if a derived class want to restore deleted operator-> of a base class?
What if multiple operator-> of the same cv-and-ref qualifiers are inherited
to a single derived class?
Perhaps these questions (and possible other issues) can be answered nicely,
but at least I consider these are not so obvious to make anybody can agree
with.
In fact, I'm a bit against of saying "synthesized operator->" because I
don't think that's what we get.
I think it's better to think "x->m" as just referring to "(*x).m" (if
operator-> is not overloaded, of course) not something like
"x.operator->().m";
according to the current language rule, "x->m" really means
"x.operator->()->m", not "x.operator->().m.", so this is quite confusing.
Sometimes dot, sometimes arrow.
What should be the decltype(x.operator->())?
How about chaining? Should it apply to the "synthesized" case?
How to figure out the "eventual return type" from operator->?
Or does "x->m" mean "x.operator->()->m" but operator-> returns some magical
type that (1) stops chaining, and (2) have the semantics of "rvalue
pointer?"
I think the simplest answer to these questions is to say "there is no
operator->."
So, for instance when we don't provide an overload for operator->, then
"x.operator->()" should be an ill-formed expression.
--
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/e2c8ee08-e0b4-4ec4-b2f4-c0f393b7c66e%40isocpp.org.
------=_Part_12210_24417304.1533127219493
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">In my opinion, multiple overloads, defaulting, deleting al=
together seem to needlessly complicate the things.<div>What if defaulted/de=
leted operator-> doesn't match cv-and-ref qualifiers of operator*?</=
div><div>What if a derived class want to restore deleted operator-> of a=
base class?</div><div>What if multiple operator-> of the same cv-and-re=
f qualifiers are inherited to a single derived class?</div><div>Perhaps the=
se questions (and possible other issues) can be answered nicely,</div><div>=
but at least I consider these are not so obvious to make anybody can agree =
with.</div><div><br></div><div>In fact, I'm a bit against of saying &qu=
ot;synthesized operator->" because I don't think that's wha=
t we get.</div><div>I think it's better to think "x->m" as=
just referring to "(*x).m" (if operator-> is not overloaded, =
of course) not something like "x.operator->().m";</div><div>ac=
cording to the current language rule, "x->m" really means &quo=
t;x.operator->()->m", not "x.operator->().m.", so t=
his is quite confusing.</div><div>Sometimes dot, sometimes arrow.</div><div=
>What should be the decltype(x.operator->())?</div><div>How about chaini=
ng? Should it apply to the "synthesized" case?</div><div>How to f=
igure out the "eventual return type" from operator->?</div><di=
v>Or does "x->m" mean "x.operator->()->m" but =
operator-> returns some magical type that (1) stops chaining, and (2) ha=
ve the semantics of "rvalue pointer?"<br></div><div><br></div><di=
v>I think the simplest answer to these questions is to say "there is n=
o operator->."</div><div>So, for instance when we don't provide=
an overload for operator->, then "x.operator->()" should b=
e an ill-formed expression.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e2c8ee08-e0b4-4ec4-b2f4-c0f393b7c66e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e2c8ee08-e0b4-4ec4-b2f4-c0f393b7c66e=
%40isocpp.org</a>.<br />
------=_Part_12210_24417304.1533127219493--
------=_Part_12209_2081723181.1533127219493--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Wed, 1 Aug 2018 07:50:00 -0700 (PDT)
Raw View
------=_Part_2753_1215894934.1533135000784
Content-Type: multipart/alternative;
boundary="----=_Part_2754_690578824.1533135000785"
------=_Part_2754_690578824.1533135000785
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno mercoled=C3=AC 1 agosto 2018 14:40:19 UTC+2, june...@gmail.com ha=
=20
scritto:
>
> In my opinion, multiple overloads, defaulting, deleting altogether seem t=
o=20
> needlessly complicate the things.
>
I'm not saying that they are necessary, just that they can be used.
What if defaulted/deleted operator-> doesn't match cv-and-ref qualifiers of=
=20
> operator*?
>
It's not selected by overload resolution, so it's not considered.
What if a derived class want to restore deleted operator-> of a base class?
>
It just re-declares the operator-> forwarding to the base class
=20
> What if multiple operator-> of the same cv-and-ref qualifiers are=20
> inherited to a single derived class?
>
That's ill-formed, as it would be with regular member functions.
In fact, I'm a bit against of saying "synthesized operator->" because I=20
> don't think that's what we get.
> I think it's better to think "x->m" as just referring to "(*x).m" (if=20
> operator-> is not overloaded, of course) not something like=20
> "x.operator->().m";
> according to the current language rule, "x->m" really means=20
> "x.operator->()->m", not "x.operator->().m.", so this is quite confusing.
> Sometimes dot, sometimes arrow.
>
That's a good point. But it's just terminology.
=20
> What should be the decltype(x.operator->())?
>
If operator->() is defaulted, there is no operator->() so that's ill-formed=
..
=20
> How about chaining? Should it apply to the "synthesized" case?
>
No. Since x->m is interpreted as (*x).m and the "dot" operator doesn't=20
chain.
=20
> How to figure out the "eventual return type" from operator->?
> Or does "x->m" mean "x.operator->()->m" but operator-> returns some=20
> magical type that (1) stops chaining, and (2) have the semantics of "rval=
ue=20
> pointer?"
>
> I think the simplest answer to these questions is to say "there is no=20
> operator->."
> So, for instance when we don't provide an overload for operator->, then=
=20
> "x.operator->()" should be an ill-formed expression.
>
We seems to agree about that.
--=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/07331c6c-bc3f-40e6-a22a-545ce530e61f%40isocpp.or=
g.
------=_Part_2754_690578824.1533135000785
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Il giorno mercoled=C3=AC 1 agosto 2018 14:40:19 UT=
C+2, june...@gmail.com ha scritto:<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">In my opinion, multiple overloads, defaulting, delet=
ing altogether seem to needlessly complicate the things.</div></blockquote>=
<div><br></div><div>I'm not saying that they are necessary, just that t=
hey can be used.</div><div> <br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div>What if defaulted/deleted operator-> doesn=
't match cv-and-ref qualifiers of operator*?</div></div></blockquote><d=
iv><br></div><div>It's not selected by overload resolution, so it's=
not considered.<br></div><div> <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>What if a derived class want to restore d=
eleted operator-> of a base class?</div></div></blockquote><div><br></di=
v><div>It just re-declares the operator-> forwarding to the base class<b=
r></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>What if multiple operator-> of the same cv-and-ref qual=
ifiers are inherited to a single derived class?</div></div></blockquote><di=
v><br></div><div>That's ill-formed, as it would be with regular member =
functions.</div><div> <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>In fact, I'm a bit against of saying "synt=
hesized operator->" because I don't think that's what we ge=
t.</div><div>I think it's better to think "x->m" as just r=
eferring to "(*x).m" (if operator-> is not overloaded, of cour=
se) not something like "x.operator->().m";</div><div>according=
to the current language rule, "x->m" really means "x.ope=
rator->()->m", not "x.operator->().m.", so this is =
quite confusing.</div><div>Sometimes dot, sometimes arrow.</div></div></blo=
ckquote><div><br></div><div>That's a good point. But it's just term=
inology.<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>What should be the decltype(x.operator->())?=
</div></div></blockquote><div><br></div><div>If operator->() is defaulte=
d, there is no operator->() so that's ill-formed.<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=
>How about chaining? Should it apply to the "synthesized" case?</=
div></div></blockquote><div><br></div><div>No. Since x->m is interpreted=
as (*x).m and the "dot" operator doesn't chain.<br></div><di=
v>=C2=A0</div><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"=
><div>How to figure out the "eventual return type" from operator-=
>?</div><div>Or does "x->m" mean "x.operator->()-&g=
t;m" but operator-> returns some magical type that (1) stops chaini=
ng, and (2) have the semantics of "rvalue pointer?"<br></div><div=
><br></div><div>I think the simplest answer to these questions is to say &q=
uot;there is no operator->."</div><div>So, for instance when we don=
't provide an overload for operator->, then "x.operator->()&=
quot; should be an ill-formed expression.</div></div></blockquote><div><br>=
</div><div>We seems to agree about that.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/07331c6c-bc3f-40e6-a22a-545ce530e61f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07331c6c-bc3f-40e6-a22a-545ce530e61f=
%40isocpp.org</a>.<br />
------=_Part_2754_690578824.1533135000785--
------=_Part_2753_1215894934.1533135000784--
.