Topic: [proposal] Single object view types (`std::view`
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 15 Nov 2016 12:38:24 -0500
Raw View
--001a11443f0c6e75d405415a6c41
Content-Type: text/plain; charset=UTF-8
So far in the STL "view" also implies read-only. "span" implies writable
(but also a range, not a single).
On Mon, Nov 14, 2016 at 11:05 PM, <joseph.thomson@gmail.com> wrote:
> I would like to present a more fleshed-out (but not yet formal) proposal
> for the single object view types, view and optional_view, that were
> previously discussed here
> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8smmfYB7siQ>
> and here
> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/u46EVqca0TE>.
> I have adjusted my design in response to some of the feedback I received,
> and have laid out responses to some of the other objections and questions
> people had. Please find full details and a reference implementation here:
>
> https://github.com/hpesoj/cpp-views
>
> view and optional_view are types used to indirectly reference another
>> object without implying ownership. view<T> is a mandatory view of an
>> object of arbitrary type T, while optional_view<T> is an optional view
>> of an object of arbitrary type T. Both view and optional_view have
>> reference-like initialization semantics and pointer-like indirection
>> semantics.
>>
>
> Thanks for taking the time to look, and please let me know what you think.
>
> Joseph
>
> --
> 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/4514ea85-0711-4bd1-
> a4c1-39e52a4d1dd3%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
Be seeing you,
Tony
--
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/CAOHCbitiNK2FavoaDnmOFhd3Se3eQujwZPWCJRw7pe8A3_qxBw%40mail.gmail.com.
--001a11443f0c6e75d405415a6c41
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">So far in the STL "view" also implies read-only.=
=C2=A0 "span" implies writable (but also a range, not a single).<=
br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, =
Nov 14, 2016 at 11:05 PM, <span dir=3D"ltr"><<a href=3D"mailto:joseph.t=
homson@gmail.com" target=3D"_blank">joseph.thomson@gmail.com</a>></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"ltr">I would like to =
present a more fleshed-out (but not yet formal) proposal for the single obj=
ect view types, <span style=3D"font-family:courier new,monospace">view</spa=
n> and <span style=3D"font-family:courier new,monospace">optional_view</spa=
n>, that were previously discussed <a href=3D"https://groups.google.com/a/i=
socpp.org/forum/#!topic/std-proposals/8smmfYB7siQ" target=3D"_blank">here</=
a> and <a href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-=
proposals/u46EVqca0TE" target=3D"_blank">here</a>. I have adjusted my desig=
n in response to some of the feedback I=20
received, and have laid out responses to some of the other=20
objections and questions people had. Please find full details and a refere=
nce implementation here:<br><br><a href=3D"https://github.com/hpesoj/cpp-vi=
ews" target=3D"_blank">https://github.com/hpesoj/cpp-<wbr>views</a><br><br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><code>view</code> and <co=
de>optional_view</code> are types used to indirectly reference another obje=
ct without implying ownership. <code>view<T></code> is a mandatory vi=
ew of an object of arbitrary type <code>T</code>, while <code>optional_view=
<T></code> is an optional view of an object of arbitrary type <code>T=
</code>. Both <code>view</code> and <code>optional_view</code> have referen=
ce-like initialization semantics and pointer-like indirection semantics.<br=
></blockquote><div><br>Thanks for taking the time to look, and please let m=
e know what you think.<br><br>Joseph<span class=3D"HOEnZb"><font color=3D"#=
888888"><br></font></span></div></div><span class=3D"HOEnZb"><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" 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/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4514=
ea85-0711-4bd1-<wbr>a4c1-39e52a4d1dd3%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><=
div>Be seeing you,<br></div>Tony<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" 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/CAOHCbitiNK2FavoaDnmOFhd3Se3eQujwZPWC=
JRw7pe8A3_qxBw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitiNK2Favoa=
DnmOFhd3Se3eQujwZPWCJRw7pe8A3_qxBw%40mail.gmail.com</a>.<br />
--001a11443f0c6e75d405415a6c41--
.
Author: joseph.thomson@gmail.com
Date: Tue, 15 Nov 2016 16:31:15 -0800 (PST)
Raw View
------=_Part_4272_2022317933.1479256276021
Content-Type: multipart/alternative;
boundary="----=_Part_4273_420062835.1479256276022"
------=_Part_4273_420062835.1479256276022
Content-Type: text/plain; charset=UTF-8
On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:
>
> So far in the STL "view" also implies read-only. "span" implies writable
> (but also a range, not a single).
>
AFAIK, string_view is the only "view" currently in the standard, and the
rationale in the string_view proposal
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html> seems
to imply that the decision to make basic_string_view
<http://en.cppreference.com/w/cpp/string/basic_string_view> immutable was
specific to that use case:
- It's more common to pass strings by reference/pointer-to-const, so the
default (the string_view type alias) should be immutable.
- While it is arguably more common to see T const& than T&, view and
optional_view have no type aliases, so there is no corresponding need
to decide a default behaviour.
- You wouldn't be able to change the length of a mutable string_view
which limits its usefulness.
- This is a string/array-specific problem not shared by view and
optional_view.
- Developers using existing string_view-like classes have found no use
case for a mutable string_view.
- There are clear use cases for mutable view and optional_view. In
addition, the string_view proposal mentions that these developers
*have* found a use case for a mutable array_view, so it is possible
that std::array_view would support the mutable use case?
- The template design would be complicated unnecessarily to support
an uncommon use case.
- The design of view and optional_view is not significantly
complicated by supporting the mutable use case, which is not nearly as
uncommon as for string_view.
That said, I am open to suggestions for alternative names. My second
favourites at the moment are observer and optional_observer, but these to
me more strongly imply immutability than view and optional_view.
On Mon, Nov 14, 2016 at 11:05 PM, <joseph....@gmail.com <javascript:>>
> wrote:
>
>> I would like to present a more fleshed-out (but not yet formal) proposal
>> for the single object view types, view and optional_view, that were
>> previously discussed here
>> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8smmfYB7siQ>
>> and here
>> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/u46EVqca0TE>.
>> I have adjusted my design in response to some of the feedback I received,
>> and have laid out responses to some of the other objections and questions
>> people had. Please find full details and a reference implementation here:
>>
>> https://github.com/hpesoj/cpp-views
>>
>> view and optional_view are types used to indirectly reference another
>>> object without implying ownership. view<T> is a mandatory view of an
>>> object of arbitrary type T, while optional_view<T> is an optional view
>>> of an object of arbitrary type T. Both view and optional_view have
>>> reference-like initialization semantics and pointer-like indirection
>>> semantics.
>>>
>>
>> Thanks for taking the time to look, and please let me know what you think.
>>
>> Joseph
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>
>
> --
> Be seeing you,
> Tony
>
--
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/f0fee82b-46f9-47cb-85db-3ace1c0de51a%40isocpp.org.
------=_Part_4273_420062835.1479256276022
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">So far i=
n the STL "view" also implies read-only.=C2=A0 "span" i=
mplies writable (but also a range, not a single).<br></div></blockquote><di=
v><br>AFAIK, string_view is the only "view" currently in the stan=
dard, and the rationale in the <span style=3D"font-family: courier new,mono=
space;">string_view</span> <a href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2013/n3762.html">proposal</a> seems to imply that the decisio=
n to make <a href=3D"http://en.cppreference.com/w/cpp/string/basic_string_v=
iew"><span style=3D"font-family: courier new,monospace;">basic_string_view<=
/span></a> immutable was specific to that use case:<br><ul><li>It's mor=
e common to pass strings by reference/pointer-to-const, so the default (the=
<span style=3D"font-family: courier new,monospace;">string_view</span> typ=
e alias) should be immutable. <br></li><ul><li>While it is arguably more co=
mmon to see <span style=3D"font-family: courier new,monospace;">T const&=
;</span> than <span style=3D"font-family: courier new,monospace;">T&</s=
pan>, <span style=3D"font-family: courier new,monospace;">view</span> and <=
span style=3D"font-family: courier new,monospace;">optional_view</span> hav=
e no type aliases, so there is no corresponding need to decide a default be=
haviour.</li></ul><li>You wouldn't be able to change the length of a mu=
table <span style=3D"font-family: courier new,monospace;">string_view</span=
> which limits its usefulness.<br></li><ul><li>This is a string/array-speci=
fic problem not shared by <span style=3D"font-family: courier new,monospace=
;">view</span> and <span style=3D"font-family: courier new,monospace;">opti=
onal_view</span>.</li></ul><li>Developers using existing <span style=3D"fon=
t-family: courier new,monospace;">string_view</span>-like classes have foun=
d no use case for a mutable <span style=3D"font-family: courier new,monospa=
ce;">string_view</span>.</li><ul><li>There are clear use cases for mutable =
<span style=3D"font-family: courier new,monospace;">view</span> and <span s=
tyle=3D"font-family: courier new,monospace;">optional_view</span>. In addit=
ion, the <span style=3D"font-family: courier new,monospace;">string_view</s=
pan> proposal mentions that these developers <i>have</i> found a use case f=
or a mutable <span style=3D"font-family: courier new,monospace;">array_view=
</span>, so it is possible that <span style=3D"font-family: courier new,mon=
ospace;">std::array_view</span> would support the mutable use case?<br></li=
></ul><li>The template design would be complicated unnecessarily to support=
an uncommon use case.</li><ul><li>The design of <span style=3D"font-family=
: courier new,monospace;">view</span> and <span style=3D"font-family: couri=
er new,monospace;">optional_view</span> is not significantly complicated by=
supporting the mutable use case, which is not nearly as uncommon as for <s=
pan style=3D"font-family: courier new,monospace;">string_view</span>.<br></=
li></ul></ul>That said, I am open to suggestions for alternative names. My =
second favourites at the moment are <span style=3D"font-family: courier new=
,monospace;">observer</span> and <span style=3D"font-family: courier new,mo=
nospace;">optional_observer</span>, but these to me more strongly imply imm=
utability than <span style=3D"font-family: courier new,monospace;">view</sp=
an> and <span style=3D"font-family: courier new,monospace;">optional_view</=
span>.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"></div><div><div class=3D"gmail_quote">On Mon, Nov 14, 2016 at 11:0=
5 PM, <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"pSaDYtDuAAAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascr=
ipt:';return true;">joseph....@gmail.com</a>></span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">I would like to present a more f=
leshed-out (but not yet formal) proposal for the single object view types, =
<span style=3D"font-family:courier new,monospace">view</span> and <span sty=
le=3D"font-family:courier new,monospace">optional_view</span>, that were pr=
eviously discussed <a href=3D"https://groups.google.com/a/isocpp.org/forum/=
#!topic/std-proposals/8smmfYB7siQ" target=3D"_blank" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!t=
opic/std-proposals/8smmfYB7siQ';return true;" onclick=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8smmf=
YB7siQ';return true;">here</a> and <a href=3D"https://groups.google.com=
/a/isocpp.org/forum/#!topic/std-proposals/u46EVqca0TE" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/a/=
isocpp.org/forum/#!topic/std-proposals/u46EVqca0TE';return true;" oncli=
ck=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic=
/std-proposals/u46EVqca0TE';return true;">here</a>. I have adjusted my =
design in response to some of the feedback I=20
received, and have laid out responses to some of the other=20
objections and questions people had. Please find full details and a refere=
nce implementation here:<br><br><a href=3D"https://github.com/hpesoj/cpp-vi=
ews" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhpesoj%2Fcpp-views\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrB3sxnnjLYqIFdwJnUKj4d4bkIQ';r=
eturn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dht=
tps%3A%2F%2Fgithub.com%2Fhpesoj%2Fcpp-views\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNGrB3sxnnjLYqIFdwJnUKj4d4bkIQ';return true;">https://github.com=
/hpesoj/cpp-<wbr>views</a><br><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><code>view</code> and <code>optional_view</code> are types used =
to indirectly reference another object without implying ownership. <code>vi=
ew<T></code> is a mandatory view of an object of arbitrary type <code=
>T</code>, while <code>optional_view<T></code> is an optional view of=
an object of arbitrary type <code>T</code>. Both <code>view</code> and <co=
de>optional_view</code> have reference-like initialization semantics and po=
inter-like indirection semantics.<br></blockquote><div><br>Thanks for takin=
g the time to look, and please let me know what you think.<br><br>Joseph<sp=
an><font color=3D"#888888"><br></font></span></div></div><span><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" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
pSaDYtDuAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:&=
#39;;return true;" onclick=3D"this.href=3D'javascript:';return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"pSaDYtDuAAAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
;javascript:';return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4514ea85-0711-4bd1-<wbr>a4c1-=
39e52a4d1dd3%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div=
dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></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" 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/f0fee82b-46f9-47cb-85db-3ace1c0de51a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f0fee82b-46f9-47cb-85db-3ace1c0de51a=
%40isocpp.org</a>.<br />
------=_Part_4273_420062835.1479256276022--
------=_Part_4272_2022317933.1479256276021--
.
Author: joseph.thomson@gmail.com
Date: Tue, 15 Nov 2016 16:57:31 -0800 (PST)
Raw View
------=_Part_2550_753755370.1479257851162
Content-Type: multipart/alternative;
boundary="----=_Part_2551_1694463418.1479257851163"
------=_Part_2551_1694463418.1479257851163
Content-Type: text/plain; charset=UTF-8
On Wednesday, 16 November 2016 08:31:16 UTC+8, joseph....@gmail.com wrote:
>
> On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:
>>
>> So far in the STL "view" also implies read-only. "span" implies writable
>> (but also a range, not a single).
>>
>
> AFAIK, string_view is the only "view" currently in the standard, and the
> rationale in the string_view proposal
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html>
> seems to imply that the decision to make basic_string_view
> <http://en.cppreference.com/w/cpp/string/basic_string_view> immutable was
> specific to that use case:
>
> - It's more common to pass strings by reference/pointer-to-const, so
> the default (the string_view type alias) should be immutable.
> - While it is arguably more common to see T const& than T&, view and
> optional_view have no type aliases, so there is no corresponding
> need to decide a default behaviour.
> - You wouldn't be able to change the length of a mutable string_view
> which limits its usefulness.
> - This is a string/array-specific problem not shared by view and
> optional_view.
>
> An additional thought on this. The inability to change the length of a
string referenced by string_view makes it significantly less useful because
strings are not usually thought of as simple arrays of characters: for
example, you would expect to be able to change "hello" to "hello, world"
just as easily as to "world", despite the fact that the former is longer
than the original string. Conversely, the ability to add extra elements to
an array_view is not required for it to be useful; indeed, std::array has a
fixed length, while there is no fixed length version of std::string. Thus,
it seems extremely likely to me that std::array_view *would* support the
mutable use case just as gsl::span does.
>
> - Developers using existing string_view-like classes have found no use
> case for a mutable string_view.
> - There are clear use cases for mutable view and optional_view. In
> addition, the string_view proposal mentions that these developers
> *have* found a use case for a mutable array_view, so it is possible
> that std::array_view would support the mutable use case?
> - The template design would be complicated unnecessarily to support
> an uncommon use case.
> - The design of view and optional_view is not significantly
> complicated by supporting the mutable use case, which is not nearly as
> uncommon as for string_view.
>
> That said, I am open to suggestions for alternative names. My second
> favourites at the moment are observer and optional_observer, but these to
> me more strongly imply immutability than view and optional_view.
>
> On Mon, Nov 14, 2016 at 11:05 PM, <joseph....@gmail.com> wrote:
>>
>>> I would like to present a more fleshed-out (but not yet formal) proposal
>>> for the single object view types, view and optional_view, that were
>>> previously discussed here
>>> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8smmfYB7siQ>
>>> and here
>>> <https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/u46EVqca0TE>.
>>> I have adjusted my design in response to some of the feedback I received,
>>> and have laid out responses to some of the other objections and questions
>>> people had. Please find full details and a reference implementation here:
>>>
>>> https://github.com/hpesoj/cpp-views
>>>
>>> view and optional_view are types used to indirectly reference another
>>>> object without implying ownership. view<T> is a mandatory view of an
>>>> object of arbitrary type T, while optional_view<T> is an optional view
>>>> of an object of arbitrary type T. Both view and optional_view have
>>>> reference-like initialization semantics and pointer-like indirection
>>>> semantics.
>>>>
>>>
>>> Thanks for taking the time to look, and please let me know what you
>>> think.
>>>
>>> Joseph
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>>
>>
>> --
>> Be seeing you,
>> Tony
>>
>
--
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/35c3c045-1c85-463b-b601-e63badad228b%40isocpp.org.
------=_Part_2551_1694463418.1479257851163
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, 16 November 2016 08:31:16 UTC+8, joseph....@=
gmail.com 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 Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So far in the STL "vi=
ew" also implies read-only.=C2=A0 "span" implies writable (b=
ut also a range, not a single).<br></div></blockquote><div><br>AFAIK, strin=
g_view is the only "view" currently in the standard, and the rati=
onale in the <span style=3D"font-family:courier new,monospace">string_view<=
/span> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n=
3762.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3762.html\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNEm9fQu11jhIbyVvlzzraWq4OjWLA';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2F=
jtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3762.html\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNEm9fQu11jhIbyVvlzzraWq4OjWLA';return true;">proposa=
l</a> seems to imply that the decision to make <a href=3D"http://en.cpprefe=
rence.com/w/cpp/string/basic_string_view" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fen.cppreference.com%2Fw%2Fcpp%2Fstring%2Fbasic_string_view\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEVlN8BgmpohtYb3ANnMCLeRfoWqg';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.=
cppreference.com%2Fw%2Fcpp%2Fstring%2Fbasic_string_view\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNEVlN8BgmpohtYb3ANnMCLeRfoWqg';return true;"><span =
style=3D"font-family:courier new,monospace">basic_string_view</span></a> im=
mutable was specific to that use case:<br><ul><li>It's more common to p=
ass strings by reference/pointer-to-const, so the default (the <span style=
=3D"font-family:courier new,monospace">string_view</span> type alias) shoul=
d be immutable. <br></li><ul><li>While it is arguably more common to see <s=
pan style=3D"font-family:courier new,monospace">T const&</span> than <s=
pan style=3D"font-family:courier new,monospace">T&</span>, <span style=
=3D"font-family:courier new,monospace">view</span> and <span style=3D"font-=
family:courier new,monospace">optional_view</span> have no type aliases, so=
there is no corresponding need to decide a default behaviour.</li></ul><li=
>You wouldn't be able to change the length of a mutable <span style=3D"=
font-family:courier new,monospace">string_view</span> which limits its usef=
ulness.<br></li><ul><li>This is a string/array-specific problem not shared =
by <span style=3D"font-family:courier new,monospace">view</span> and <span =
style=3D"font-family:courier new,monospace">optional_view</span>.</li></ul>=
</ul></div></div></blockquote><div>An additional thought on this. The inabi=
lity to change the length of a string referenced by <span style=3D"font-fam=
ily: courier new,monospace;">string_view</span> makes it significantly less=
useful because strings are not usually thought of as simple arrays of char=
acters: for example, you would expect to be able to change <span style=3D"f=
ont-family: courier new,monospace;">"hello"</span> to <span style=
=3D"font-family: courier new,monospace;">"hello, world"</span> ju=
st as easily as to <span style=3D"font-family: courier new,monospace;">&quo=
t;world"</span>, despite the fact that the former is longer than the o=
riginal string. Conversely, the ability to add extra elements to an <span s=
tyle=3D"font-family: courier new,monospace;">array_view</span> is not requi=
red for it to be useful; indeed, <span style=3D"font-family: courier new,mo=
nospace;">std::array</span> has a fixed length, while there is no fixed len=
gth version of <span style=3D"font-family: courier new,monospace;">std::str=
ing</span>. Thus, it seems extremely likely to me that <span style=3D"font-=
family: courier new,monospace;">std::array_view</span> <i>would</i> support=
the mutable use case just as <span style=3D"font-family: courier new,monos=
pace;">gsl::span</span> does.<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><ul><li>Developers using existing <span styl=
e=3D"font-family:courier new,monospace">string_view</span>-like classes hav=
e found no use case for a mutable <span style=3D"font-family:courier new,mo=
nospace">string_view</span>.</li><ul><li>There are clear use cases for muta=
ble <span style=3D"font-family:courier new,monospace">view</span> and <span=
style=3D"font-family:courier new,monospace">optional_view</span>. In addit=
ion, the <span style=3D"font-family:courier new,monospace">string_view</spa=
n> proposal mentions that these developers <i>have</i> found a use case for=
a mutable <span style=3D"font-family:courier new,monospace">array_view</sp=
an>, so it is possible that <span style=3D"font-family:courier new,monospac=
e">std::array_view</span> would support the mutable use case?<br></li></ul>=
<li>The template design would be complicated unnecessarily to support an un=
common use case.</li><ul><li>The design of <span style=3D"font-family:couri=
er new,monospace">view</span> and <span style=3D"font-family:courier new,mo=
nospace">optional_view</span> is not significantly complicated by supportin=
g the mutable use case, which is not nearly as uncommon as for <span style=
=3D"font-family:courier new,monospace">string_view</span>.<br></li></ul></u=
l>That said, I am open to suggestions for alternative names. My second favo=
urites at the moment are <span style=3D"font-family:courier new,monospace">=
observer</span> and <span style=3D"font-family:courier new,monospace">optio=
nal_observer</span>, but these to me more strongly imply immutability than =
<span style=3D"font-family:courier new,monospace">view</span> and <span sty=
le=3D"font-family:courier new,monospace">optional_view</span>.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"></div><div><div c=
lass=3D"gmail_quote">On Mon, Nov 14, 2016 at 11:05 PM, <span dir=3D"ltr">&=
lt;<a rel=3D"nofollow">joseph....@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">I would like to present a more fl=
eshed-out (but not yet formal) proposal for the single object view types, <=
span style=3D"font-family:courier new,monospace">view</span> and <span styl=
e=3D"font-family:courier new,monospace">optional_view</span>, that were pre=
viously discussed <a href=3D"https://groups.google.com/a/isocpp.org/forum/#=
!topic/std-proposals/8smmfYB7siQ" rel=3D"nofollow" target=3D"_blank" onmous=
edown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!to=
pic/std-proposals/8smmfYB7siQ';return true;" onclick=3D"this.href=3D=
9;https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/8smmfY=
B7siQ';return true;">here</a> and <a href=3D"https://groups.google.com/=
a/isocpp.org/forum/#!topic/std-proposals/u46EVqca0TE" rel=3D"nofollow" targ=
et=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/a/i=
socpp.org/forum/#!topic/std-proposals/u46EVqca0TE';return true;" onclic=
k=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/=
std-proposals/u46EVqca0TE';return true;">here</a>. I have adjusted my d=
esign in response to some of the feedback I=20
received, and have laid out responses to some of the other=20
objections and questions people had. Please find full details and a refere=
nce implementation here:<br><br><a href=3D"https://github.com/hpesoj/cpp-vi=
ews" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'htt=
ps://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fhpesoj%2Fcpp-views\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGrB3sxnnjLYqIFdwJnUKj4d4bkIQ';r=
eturn true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dht=
tps%3A%2F%2Fgithub.com%2Fhpesoj%2Fcpp-views\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNGrB3sxnnjLYqIFdwJnUKj4d4bkIQ';return true;">https://github.com=
/hpesoj/cpp-<wbr>views</a><br><br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><code>view</code> and <code>optional_view</code> are types used =
to indirectly reference another object without implying ownership. <code>vi=
ew<T></code> is a mandatory view of an object of arbitrary type <code=
>T</code>, while <code>optional_view<T></code> is an optional view of=
an object of arbitrary type <code>T</code>. Both <code>view</code> and <co=
de>optional_view</code> have reference-like initialization semantics and po=
inter-like indirection semantics.<br></blockquote><div><br>Thanks for takin=
g the time to look, and please let me know what you think.<br><br>Joseph<sp=
an><font color=3D"#888888"><br></font></span></div></div><span><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" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</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/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/4514ea85-0711-4bd1-a4c1-39e52a4d1dd3%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/4514ea85-0711-4bd1-<wbr>a4c1-=
39e52a4d1dd3%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div><div=
dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div>
</blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/35c3c045-1c85-463b-b601-e63badad228b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/35c3c045-1c85-463b-b601-e63badad228b=
%40isocpp.org</a>.<br />
------=_Part_2551_1694463418.1479257851163--
------=_Part_2550_753755370.1479257851162--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 15 Nov 2016 20:33:09 -0800 (PST)
Raw View
------=_Part_4528_1536464210.1479270789532
Content-Type: multipart/alternative;
boundary="----=_Part_4529_561034725.1479270789532"
------=_Part_4529_561034725.1479270789532
Content-Type: text/plain; charset=UTF-8
On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, joseph....@gmail.com
wrote:
>
> On Wednesday, 16 November 2016 08:31:16 UTC+8, joseph....@gmail.com wrote:
>>
>> On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:
>>>
>>> So far in the STL "view" also implies read-only. "span" implies
>>> writable (but also a range, not a single).
>>>
>>
>> AFAIK, string_view is the only "view" currently in the standard, and the
>> rationale in the string_view proposal
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html>
>> seems to imply that the decision to make basic_string_view
>> <http://en.cppreference.com/w/cpp/string/basic_string_view> immutable
>> was specific to that use case:
>>
>> - It's more common to pass strings by reference/pointer-to-const, so
>> the default (the string_view type alias) should be immutable.
>> - While it is arguably more common to see T const& than T&, view and
>> optional_view have no type aliases, so there is no corresponding
>> need to decide a default behaviour.
>> - You wouldn't be able to change the length of a mutable string_view
>> which limits its usefulness.
>> - This is a string/array-specific problem not shared by view and
>> optional_view.
>>
>> An additional thought on this. The inability to change the length of a
> string referenced by string_view makes it significantly less useful
> because strings are not usually thought of as simple arrays of characters:
> for example, you would expect to be able to change "hello" to "hello,
> world" just as easily as to "world", despite the fact that the former is
> longer than the original string. Conversely, the ability to add extra
> elements to an array_view is not required for it to be useful; indeed,
> std::array has a fixed length, while there is no fixed length version of
> std::string. Thus, it seems extremely likely to me that std::array_view
> *would* support the mutable use case just as gsl::span does.
>
And yet, the original proposed array_ref
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3334.html> did
not support mutable arrays.
--
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/2a2778b5-d404-435e-b8c4-93faba2e8f2d%40isocpp.org.
------=_Part_4529_561034725.1479270789532
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5,=
joseph....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">On Wednesday, 16 November 2016 08:31:16 UTC+8, <a>joseph....=
@gmail.com</a> wrote:<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"l=
tr">On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So far in the STL "vi=
ew" also implies read-only.=C2=A0 "span" implies writable (b=
ut also a range, not a single).<br></div></blockquote><div><br>AFAIK, strin=
g_view is the only "view" currently in the standard, and the rati=
onale in the <span style=3D"font-family:courier new,monospace">string_view<=
/span> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n=
3762.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3762.html\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNEm9fQu11jhIbyVvlzzraWq4OjWLA';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2F=
jtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3762.html\x26sa\x3dD\x26sntz\x=
3d1\x26usg\x3dAFQjCNEm9fQu11jhIbyVvlzzraWq4OjWLA';return true;">proposa=
l</a> seems to imply that the decision to make <a href=3D"http://en.cpprefe=
rence.com/w/cpp/string/basic_string_view" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F=
%2Fen.cppreference.com%2Fw%2Fcpp%2Fstring%2Fbasic_string_view\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNEVlN8BgmpohtYb3ANnMCLeRfoWqg';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.=
cppreference.com%2Fw%2Fcpp%2Fstring%2Fbasic_string_view\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNEVlN8BgmpohtYb3ANnMCLeRfoWqg';return true;"><span =
style=3D"font-family:courier new,monospace">basic_string_view</span></a> im=
mutable was specific to that use case:<br><ul><li>It's more common to p=
ass strings by reference/pointer-to-const, so the default (the <span style=
=3D"font-family:courier new,monospace">string_view</span> type alias) shoul=
d be immutable. <br></li><ul><li>While it is arguably more common to see <s=
pan style=3D"font-family:courier new,monospace">T const&</span> than <s=
pan style=3D"font-family:courier new,monospace">T&</span>, <span style=
=3D"font-family:courier new,monospace">view</span> and <span style=3D"font-=
family:courier new,monospace">optional_view</span> have no type aliases, so=
there is no corresponding need to decide a default behaviour.</li></ul><li=
>You wouldn't be able to change the length of a mutable <span style=3D"=
font-family:courier new,monospace">string_view</span> which limits its usef=
ulness.<br></li><ul><li>This is a string/array-specific problem not shared =
by <span style=3D"font-family:courier new,monospace">view</span> and <span =
style=3D"font-family:courier new,monospace">optional_view</span>.</li></ul>=
</ul></div></div></blockquote><div>An additional thought on this. The inabi=
lity to change the length of a string referenced by <span style=3D"font-fam=
ily:courier new,monospace">string_view</span> makes it significantly less u=
seful because strings are not usually thought of as simple arrays of charac=
ters: for example, you would expect to be able to change <span style=3D"fon=
t-family:courier new,monospace">"hello"</span> to <span style=3D"=
font-family:courier new,monospace">"hello, world"</span> just as =
easily as to <span style=3D"font-family:courier new,monospace">"world&=
quot;</span>, despite the fact that the former is longer than the original =
string. Conversely, the ability to add extra elements to an <span style=3D"=
font-family:courier new,monospace">array_view</span> is not required for it=
to be useful; indeed, <span style=3D"font-family:courier new,monospace">st=
d::array</span> has a fixed length, while there is no fixed length version =
of <span style=3D"font-family:courier new,monospace">std::string</span>. Th=
us, it seems extremely likely to me that <span style=3D"font-family:courier=
new,monospace">std::array_view</span> <i>would</i> support the mutable use=
case just as <span style=3D"font-family:courier new,monospace">gsl::span</=
span> does.<br></div></div></blockquote><div><br>And yet, <a href=3D"http:/=
/www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3334.html">the original =
proposed array_ref</a> did not support mutable arrays.</div><br></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/2a2778b5-d404-435e-b8c4-93faba2e8f2d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2a2778b5-d404-435e-b8c4-93faba2e8f2d=
%40isocpp.org</a>.<br />
------=_Part_4529_561034725.1479270789532--
------=_Part_4528_1536464210.1479270789532--
.
Author: joseph.thomson@gmail.com
Date: Tue, 15 Nov 2016 22:52:05 -0800 (PST)
Raw View
------=_Part_3547_1328688646.1479279125487
Content-Type: multipart/alternative;
boundary="----=_Part_3548_1433067843.1479279125487"
------=_Part_3548_1433067843.1479279125487
Content-Type: text/plain; charset=UTF-8
On Wednesday, 16 November 2016 12:33:09 UTC+8, Nicol Bolas wrote:
>
>
>
> On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, joseph....@gmail.com
> wrote:
>>
>> On Wednesday, 16 November 2016 08:31:16 UTC+8, joseph....@gmail.com
>> wrote:
>>>
>>> On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:
>>>>
>>>> So far in the STL "view" also implies read-only. "span" implies
>>>> writable (but also a range, not a single).
>>>>
>>>
>>> AFAIK, string_view is the only "view" currently in the standard, and the
>>> rationale in the string_view proposal
>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html>
>>> seems to imply that the decision to make basic_string_view
>>> <http://en.cppreference.com/w/cpp/string/basic_string_view> immutable
>>> was specific to that use case:
>>>
>>> - It's more common to pass strings by reference/pointer-to-const, so
>>> the default (the string_view type alias) should be immutable.
>>> - While it is arguably more common to see T const& than T&, view and
>>> optional_view have no type aliases, so there is no corresponding
>>> need to decide a default behaviour.
>>> - You wouldn't be able to change the length of a mutable string_view
>>> which limits its usefulness.
>>> - This is a string/array-specific problem not shared by view and
>>> optional_view.
>>>
>>> An additional thought on this. The inability to change the length of a
>> string referenced by string_view makes it significantly less useful
>> because strings are not usually thought of as simple arrays of characters:
>> for example, you would expect to be able to change "hello" to "hello,
>> world" just as easily as to "world", despite the fact that the former is
>> longer than the original string. Conversely, the ability to add extra
>> elements to an array_view is not required for it to be useful; indeed,
>> std::array has a fixed length, while there is no fixed length version of
>> std::string. Thus, it seems extremely likely to me that std::array_view
>> *would* support the mutable use case just as gsl::span does.
>>
>
> And yet, the original proposed array_ref
> <http://www.google.com/url?q=http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html&sa=D&sntz=1&usg=AFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ>
> did not support mutable arrays.
>
Perhaps opinion has shifted since then, because it seems that more recent
proposals do:
- Multidimensional bounds, offset and arra
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html>
y_view, revision 7
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html>
(2015-05-07)
- array_view: bounds-safe views for sequences of objects
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0122r0.pdf>
(2015-09-25)
--
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/91f53ef7-2c08-4221-afdd-0a3cf0081e26%40isocpp.org.
------=_Part_3548_1433067843.1479279125487
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, 16 November 2016 12:33:09 UTC+8, Nicol Bolas=
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"><br><=
br>On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, <a>joseph....@gmail.c=
om</a> wrote:<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">On We=
dnesday, 16 November 2016 08:31:16 UTC+8, <a>joseph....@gmail.com</a> 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">On Wednesday, 16=
November 2016 01:38:28 UTC+8, Tony V E wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr">So far in the STL "view" also implie=
s read-only.=C2=A0 "span" implies writable (but also a range, not=
a single).<br></div></blockquote><div><br>AFAIK, string_view is the only &=
quot;view" currently in the standard, and the rationale in the <span s=
tyle=3D"font-family:courier new,monospace">string_view</span> <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html" rel=3D"no=
follow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fp=
apers%2F2013%2Fn3762.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEm9fQu11j=
hIbyVvlzzraWq4OjWLA';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fpapers%2F2013%2Fn3762.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
Em9fQu11jhIbyVvlzzraWq4OjWLA';return true;">proposal</a> seems to imply=
that the decision to make <a href=3D"http://en.cppreference.com/w/cpp/stri=
ng/basic_string_view" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"thi=
s.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.c=
om%2Fw%2Fcpp%2Fstring%2Fbasic_string_view\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNEVlN8BgmpohtYb3ANnMCLeRfoWqg';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fen.cppreference.com%2Fw=
%2Fcpp%2Fstring%2Fbasic_string_view\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NEVlN8BgmpohtYb3ANnMCLeRfoWqg';return true;"><span style=3D"font-family=
:courier new,monospace">basic_string_view</span></a> immutable was specific=
to that use case:<br><ul><li>It's more common to pass strings by refer=
ence/pointer-to-const, so the default (the <span style=3D"font-family:couri=
er new,monospace">string_view</span> type alias) should be immutable. <br><=
/li><ul><li>While it is arguably more common to see <span style=3D"font-fam=
ily:courier new,monospace">T const&</span> than <span style=3D"font-fam=
ily:courier new,monospace">T&</span>, <span style=3D"font-family:courie=
r new,monospace">view</span> and <span style=3D"font-family:courier new,mon=
ospace">optional_view</span> have no type aliases, so there is no correspon=
ding need to decide a default behaviour.</li></ul><li>You wouldn't be a=
ble to change the length of a mutable <span style=3D"font-family:courier ne=
w,monospace">string_view</span> which limits its usefulness.<br></li><ul><l=
i>This is a string/array-specific problem not shared by <span style=3D"font=
-family:courier new,monospace">view</span> and <span style=3D"font-family:c=
ourier new,monospace">optional_view</span>.</li></ul></ul></div></div></blo=
ckquote><div>An additional thought on this. The inability to change the len=
gth of a string referenced by <span style=3D"font-family:courier new,monosp=
ace">string_view</span> makes it significantly less useful because strings =
are not usually thought of as simple arrays of characters: for example, you=
would expect to be able to change <span style=3D"font-family:courier new,m=
onospace">"hello"</span> to <span style=3D"font-family:courier ne=
w,monospace">"hello, world"</span> just as easily as to <span sty=
le=3D"font-family:courier new,monospace">"world"</span>, despite =
the fact that the former is longer than the original string. Conversely, th=
e ability to add extra elements to an <span style=3D"font-family:courier ne=
w,monospace">array_view</span> is not required for it to be useful; indeed,=
<span style=3D"font-family:courier new,monospace">std::array</span> has a =
fixed length, while there is no fixed length version of <span style=3D"font=
-family:courier new,monospace">std::string</span>. Thus, it seems extremely=
likely to me that <span style=3D"font-family:courier new,monospace">std::a=
rray_view</span> <i>would</i> support the mutable use case just as <span st=
yle=3D"font-family:courier new,monospace">gsl::span</span> does.<br></div><=
/div></blockquote><div><br>And yet, <a href=3D"http://www.google.com/url?q=
=3Dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F201=
2%2Fn3334.html&sa=3DD&sntz=3D1&usg=3DAFQjCNG_ttOUsXVKaIvFFZ_1Xh=
8wEaxJwQ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC2=
2%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ';return true;" onclick=3D"this.h=
ref=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJ=
TC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ';return true;">the orig=
inal proposed array_ref</a> did not support mutable arrays.</div></div></bl=
ockquote><div><br>Perhaps opinion has shifted since then, because it seems =
that more recent proposals do:<br><ul><li><a href=3D"http://www.open-std.or=
g/jtc1/sc22/wg21/docs/papers/2015/n4512.html">Multidimensional bounds, <spa=
n style=3D"font-family: courier new,monospace;">offset</span> and <span sty=
le=3D"font-family: courier new,monospace;">arra</span></a><a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html"><span style=
=3D"font-family: courier new,monospace;">y_view</span>, revision 7</a> (201=
5-05-07)</li><li><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2015/p0122r0.pdf"><span style=3D"font-family: courier new,monospace;">a=
rray_view</span>: bounds-safe views for sequences of objects</a> (2015-09-2=
5)</li></ul></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/91f53ef7-2c08-4221-afdd-0a3cf0081e26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91f53ef7-2c08-4221-afdd-0a3cf0081e26=
%40isocpp.org</a>.<br />
------=_Part_3548_1433067843.1479279125487--
------=_Part_3547_1328688646.1479279125487--
.
Author: joseph.thomson@gmail.com
Date: Sat, 19 Nov 2016 08:30:37 -0800 (PST)
Raw View
------=_Part_5230_367601801.1479573037415
Content-Type: multipart/alternative;
boundary="----=_Part_5231_1357524827.1479573037416"
------=_Part_5231_1357524827.1479573037416
Content-Type: text/plain; charset=UTF-8
It has just occurred to me that "view" may not be appropriate for another
reason. The comparison operators for view and optional_view have
pointer-like semantics, while std::string_view and the proposed
std::array_view have comparison operators with value-/reference-like
semantics. I believe this makes the term "view" inappropriate in this case.
I am now trying to think of other possible names. So far I only have:
- observer and optional_observer
- indirect and optional_indirect
The term "observer" is quite descriptive, but I worry that it implies some
implementation of the observer pattern. The term "indirect" is nice because
it reads quite well grammatically:
void foo(indirect<int> i); // function takes an `int` indirectly
And I am aware of Jonathan Coe's proposal for a deep-copying smart pointer
type called indirect, but I personally feel a name that describes its
deep-copying, pointer-like nature would be more appropriate (e.g. its
original name, deep_ptr), so I consider the name still up for grabs. And I
would also consider ref and optional_ref, if std::ref weren't already a
factory function for std::reference_wrapper.
I would be interested to hear any other opinions or suggestions regarding
naming.
On Wednesday, 16 November 2016 14:52:05 UTC+8, joseph....@gmail.com wrote:
>
> On Wednesday, 16 November 2016 12:33:09 UTC+8, Nicol Bolas wrote:
>>
>>
>>
>> On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, joseph....@gmail.com
>> wrote:
>>>
>>> On Wednesday, 16 November 2016 08:31:16 UTC+8, joseph....@gmail.com
>>> wrote:
>>>>
>>>> On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:
>>>>>
>>>>> So far in the STL "view" also implies read-only. "span" implies
>>>>> writable (but also a range, not a single).
>>>>>
>>>>
>>>> AFAIK, string_view is the only "view" currently in the standard, and
>>>> the rationale in the string_view proposal
>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html>
>>>> seems to imply that the decision to make basic_string_view
>>>> <http://en.cppreference.com/w/cpp/string/basic_string_view> immutable
>>>> was specific to that use case:
>>>>
>>>> - It's more common to pass strings by reference/pointer-to-const,
>>>> so the default (the string_view type alias) should be immutable.
>>>> - While it is arguably more common to see T const& than T&, view
>>>> and optional_view have no type aliases, so there is no
>>>> corresponding need to decide a default behaviour.
>>>> - You wouldn't be able to change the length of a mutable string_view
>>>> which limits its usefulness.
>>>> - This is a string/array-specific problem not shared by view and
>>>> optional_view.
>>>>
>>>> An additional thought on this. The inability to change the length of a
>>> string referenced by string_view makes it significantly less useful
>>> because strings are not usually thought of as simple arrays of characters:
>>> for example, you would expect to be able to change "hello" to "hello,
>>> world" just as easily as to "world", despite the fact that the former
>>> is longer than the original string. Conversely, the ability to add extra
>>> elements to an array_view is not required for it to be useful; indeed,
>>> std::array has a fixed length, while there is no fixed length version
>>> of std::string. Thus, it seems extremely likely to me that
>>> std::array_view *would* support the mutable use case just as gsl::span
>>> does.
>>>
>>
>> And yet, the original proposed array_ref
>> <http://www.google.com/url?q=http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html&sa=D&sntz=1&usg=AFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ>
>> did not support mutable arrays.
>>
>
> Perhaps opinion has shifted since then, because it seems that more recent
> proposals do:
>
> - Multidimensional bounds, offset and arra
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html>
> y_view, revision 7
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html>
> (2015-05-07)
> - array_view: bounds-safe views for sequences of objects
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0122r0.pdf>
> (2015-09-25)
>
>
--
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/c62241d5-0e3d-4925-965f-e84d6a2631a0%40isocpp.org.
------=_Part_5231_1357524827.1479573037416
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It has just occurred to me that "view" may not b=
e appropriate for another reason. The comparison operators for <span style=
=3D"font-family: courier new,monospace;">view</span> and <span style=3D"fon=
t-family: courier new,monospace;">optional_view</span> have pointer-like se=
mantics, while <span style=3D"font-family: courier new,monospace;">std::str=
ing_view</span> and the proposed <span style=3D"font-family: courier new,mo=
nospace;">std::array_view</span> have comparison operators with value-/refe=
rence-like semantics. I believe this makes the term "view" inappr=
opriate in this case.<br><br>I am now trying to think of other possible nam=
es. So far I only have:<br><ul><li><span style=3D"font-family: courier new,=
monospace;">observer</span> and <span style=3D"font-family: courier new,mon=
ospace;">optional_observer</span></li><li><span style=3D"font-family: couri=
er new,monospace;">indirect</span> and <span style=3D"font-family: courier =
new,monospace;">optional_indirect</span></li></ul><p>The term "observe=
r" is quite descriptive, but I worry that it implies some implementati=
on of the observer pattern. The term "indirect" is nice because i=
t reads quite well grammatically:</p><p><br></p><p></p><div style=3D"backgr=
ound-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-st=
yle: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyp=
rint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">indirect</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify"><int></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">=
// function takes an `int` indirectly</span></div></code></div><p></p><p><b=
r></p><p>And I am aware of Jonathan Coe's proposal for a deep-copying s=
mart pointer type called <span style=3D"font-family: courier new,monospace;=
">indirect</span>, but I personally feel a name that describes its deep-cop=
ying, pointer-like nature would be more appropriate (e.g. its original name=
, <span style=3D"font-family: courier new,monospace;">deep_ptr</span>), so =
I consider the name still up for grabs. And I would also consider <span sty=
le=3D"font-family: courier new,monospace;">ref</span> and <span style=3D"fo=
nt-family: courier new,monospace;">optional_ref</span>, if <span style=3D"f=
ont-family: courier new,monospace;">std::ref</span> weren't already a f=
actory function for <span style=3D"font-family: courier new,monospace;">std=
::reference_wrapper</span>.</p><p><br></p><p>I would be interested to hear =
any other opinions or suggestions regarding naming.<br></p><br>On Wednesday=
, 16 November 2016 14:52:05 UTC+8, joseph....@gmail.com wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Wednesday, 16 November=
2016 12:33:09 UTC+8, Nicol Bolas 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"><br><br>On Tuesday, November 15, 2016 at 7:57:31 PM =
UTC-5, <a>joseph....@gmail.com</a> 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 Wednesday, 16 November 2016 08:31:16 UTC+8, <a>jo=
seph....@gmail.com</a> wrote:<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">On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So far in the STL =
"view" also implies read-only.=C2=A0 "span" implies wri=
table (but also a range, not a single).<br></div></blockquote><div><br>AFAI=
K, string_view is the only "view" currently in the standard, and =
the rationale in the <span style=3D"font-family:courier new,monospace">stri=
ng_view</span> <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2013/n3762.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fj=
tc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3762.html\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNEm9fQu11jhIbyVvlzzraWq4OjWLA';return true;" onclick=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2013%2Fn3762.html\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNEm9fQu11jhIbyVvlzzraWq4OjWLA';return true;=
">proposal</a> seems to imply that the decision to make <a href=3D"http://e=
n.cppreference.com/w/cpp/string/basic_string_view" rel=3D"nofollow" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3d=
http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fstring%2Fbasic_string_view\x26=
sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEVlN8BgmpohtYb3ANnMCLeRfoWqg';retu=
rn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3=
A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fstring%2Fbasic_string_view\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEVlN8BgmpohtYb3ANnMCLeRfoWqg';return tru=
e;"><span style=3D"font-family:courier new,monospace">basic_string_view</sp=
an></a> immutable was specific to that use case:<br><ul><li>It's more c=
ommon to pass strings by reference/pointer-to-const, so the default (the <s=
pan style=3D"font-family:courier new,monospace">string_view</span> type ali=
as) should be immutable. <br></li><ul><li>While it is arguably more common =
to see <span style=3D"font-family:courier new,monospace">T const&</span=
> than <span style=3D"font-family:courier new,monospace">T&</span>, <sp=
an style=3D"font-family:courier new,monospace">view</span> and <span style=
=3D"font-family:courier new,monospace">optional_view</span> have no type al=
iases, so there is no corresponding need to decide a default behaviour.</li=
></ul><li>You wouldn't be able to change the length of a mutable <span =
style=3D"font-family:courier new,monospace">string_view</span> which limits=
its usefulness.<br></li><ul><li>This is a string/array-specific problem no=
t shared by <span style=3D"font-family:courier new,monospace">view</span> a=
nd <span style=3D"font-family:courier new,monospace">optional_view</span>.<=
/li></ul></ul></div></div></blockquote><div>An additional thought on this. =
The inability to change the length of a string referenced by <span style=3D=
"font-family:courier new,monospace">string_view</span> makes it significant=
ly less useful because strings are not usually thought of as simple arrays =
of characters: for example, you would expect to be able to change <span sty=
le=3D"font-family:courier new,monospace">"hello"</span> to <span =
style=3D"font-family:courier new,monospace">"hello, world"</span>=
just as easily as to <span style=3D"font-family:courier new,monospace">&qu=
ot;world"</span>, despite the fact that the former is longer than the =
original string. Conversely, the ability to add extra elements to an <span =
style=3D"font-family:courier new,monospace">array_view</span> is not requir=
ed for it to be useful; indeed, <span style=3D"font-family:courier new,mono=
space">std::array</span> has a fixed length, while there is no fixed length=
version of <span style=3D"font-family:courier new,monospace">std::string</=
span>. Thus, it seems extremely likely to me that <span style=3D"font-famil=
y:courier new,monospace">std::array_view</span> <i>would</i> support the mu=
table use case just as <span style=3D"font-family:courier new,monospace">gs=
l::span</span> does.<br></div></div></blockquote><div><br>And yet, <a href=
=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC=
22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html&sa=3DD&sntz=3D1&u=
sg=3DAFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ" rel=3D"nofollow" target=3D"_blank"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%=
2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html=
\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ';=
return true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dht=
tp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn=
3334.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEax=
JwQ';return true;">the original proposed array_ref</a> did not support =
mutable arrays.</div></div></blockquote><div><br>Perhaps opinion has shifte=
d since then, because it seems that more recent proposals do:<br><ul><li><a=
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21=
%2Fdocs%2Fpapers%2F2015%2Fn4512.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNG-oUYUAplukSLlg2xmfv-RY9yIrQ';return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4512.html\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNG-oUYUAplukSLlg2xmfv-RY9yIrQ';return true;">Multidimensional=
bounds, <span style=3D"font-family:courier new,monospace">offset</span> an=
d <span style=3D"font-family:courier new,monospace">arra</span></a><a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdo=
cs%2Fpapers%2F2015%2Fn4512.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG-o=
UYUAplukSLlg2xmfv-RY9yIrQ';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2F=
wg21%2Fdocs%2Fpapers%2F2015%2Fn4512.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNG-oUYUAplukSLlg2xmfv-RY9yIrQ';return true;"><span style=3D"font-f=
amily:courier new,monospace">y_view</span>, revision 7</a> (2015-05-07)</li=
><li><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p01=
22r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0122r0.pdf\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNH8DDcsk4uOnwjBBPy_qT8XjgQmrw';return true;" onclick=3D"this.=
href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2F=
jtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0122r0.pdf\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNH8DDcsk4uOnwjBBPy_qT8XjgQmrw';return true;"><span =
style=3D"font-family:courier new,monospace">array_view</span>: bounds-safe =
views for sequences of objects</a> (2015-09-25)</li></ul></div></div></bloc=
kquote></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/c62241d5-0e3d-4925-965f-e84d6a2631a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c62241d5-0e3d-4925-965f-e84d6a2631a0=
%40isocpp.org</a>.<br />
------=_Part_5231_1357524827.1479573037416--
------=_Part_5230_367601801.1479573037415--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Sat, 19 Nov 2016 14:09:48 -0500
Raw View
--089e013c6b2aa0c8e00541ac2a0a
Content-Type: text/plain; charset=UTF-8
Jonathan's class was recently changed to polymorphic_value. (And/or
clone_ptr if it gets split into 2 classes)
On Sat, Nov 19, 2016 at 11:30 AM, <joseph.thomson@gmail.com> wrote:
> It has just occurred to me that "view" may not be appropriate for another
> reason. The comparison operators for view and optional_view have
> pointer-like semantics, while std::string_view and the proposed
> std::array_view have comparison operators with value-/reference-like
> semantics. I believe this makes the term "view" inappropriate in this case.
>
> I am now trying to think of other possible names. So far I only have:
>
> - observer and optional_observer
> - indirect and optional_indirect
>
> The term "observer" is quite descriptive, but I worry that it implies some
> implementation of the observer pattern. The term "indirect" is nice because
> it reads quite well grammatically:
>
>
> void foo(indirect<int> i); // function takes an `int` indirectly
>
>
> And I am aware of Jonathan Coe's proposal for a deep-copying smart pointer
> type called indirect, but I personally feel a name that describes its
> deep-copying, pointer-like nature would be more appropriate (e.g. its
> original name, deep_ptr), so I consider the name still up for grabs. And
> I would also consider ref and optional_ref, if std::ref weren't already a
> factory function for std::reference_wrapper.
>
>
> I would be interested to hear any other opinions or suggestions regarding
> naming.
>
> On Wednesday, 16 November 2016 14:52:05 UTC+8, joseph....@gmail.com wrote:
>>
>> On Wednesday, 16 November 2016 12:33:09 UTC+8, Nicol Bolas wrote:
>>>
>>>
>>>
>>> On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, joseph....@gmail.com
>>> wrote:
>>>>
>>>> On Wednesday, 16 November 2016 08:31:16 UTC+8, joseph....@gmail.com
>>>> wrote:
>>>>>
>>>>> On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:
>>>>>>
>>>>>> So far in the STL "view" also implies read-only. "span" implies
>>>>>> writable (but also a range, not a single).
>>>>>>
>>>>>
>>>>> AFAIK, string_view is the only "view" currently in the standard, and
>>>>> the rationale in the string_view proposal
>>>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html>
>>>>> seems to imply that the decision to make basic_string_view
>>>>> <http://en.cppreference.com/w/cpp/string/basic_string_view> immutable
>>>>> was specific to that use case:
>>>>>
>>>>> - It's more common to pass strings by reference/pointer-to-const,
>>>>> so the default (the string_view type alias) should be immutable.
>>>>> - While it is arguably more common to see T const& than T&, view
>>>>> and optional_view have no type aliases, so there is no
>>>>> corresponding need to decide a default behaviour.
>>>>> - You wouldn't be able to change the length of a mutable
>>>>> string_view which limits its usefulness.
>>>>> - This is a string/array-specific problem not shared by view and
>>>>> optional_view.
>>>>>
>>>>> An additional thought on this. The inability to change the length of a
>>>> string referenced by string_view makes it significantly less useful
>>>> because strings are not usually thought of as simple arrays of characters:
>>>> for example, you would expect to be able to change "hello" to "hello,
>>>> world" just as easily as to "world", despite the fact that the former
>>>> is longer than the original string. Conversely, the ability to add extra
>>>> elements to an array_view is not required for it to be useful; indeed,
>>>> std::array has a fixed length, while there is no fixed length version
>>>> of std::string. Thus, it seems extremely likely to me that
>>>> std::array_view *would* support the mutable use case just as gsl::span
>>>> does.
>>>>
>>>
>>> And yet, the original proposed array_ref
>>> <http://www.google.com/url?q=http%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html&sa=D&sntz=1&usg=AFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ>
>>> did not support mutable arrays.
>>>
>>
>> Perhaps opinion has shifted since then, because it seems that more recent
>> proposals do:
>>
>> - Multidimensional bounds, offset and arra
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html>
>> y_view, revision 7
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html>
>> (2015-05-07)
>> - array_view: bounds-safe views for sequences of objects
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0122r0.pdf>
>> (2015-09-25)
>>
>> --
> 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/c62241d5-0e3d-4925-
> 965f-e84d6a2631a0%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c62241d5-0e3d-4925-965f-e84d6a2631a0%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
Be seeing you,
Tony
--
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/CAOHCbiub3y%2Baejg9dkW%3DicGkvRk%2Bw_qQ%2BKAfK3weCR3U7Dyyvw%40mail.gmail.com.
--089e013c6b2aa0c8e00541ac2a0a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Jonathan's class was recently changed to polymorphic_v=
alue. (And/or clone_ptr if it gets split into 2 classes)<br></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Nov 19, 2016 at 11=
:30 AM, <span dir=3D"ltr"><<a href=3D"mailto:joseph.thomson@gmail.com" =
target=3D"_blank">joseph.thomson@gmail.com</a>></span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">It has just occurred to me that &q=
uot;view" may not be appropriate for another reason. The comparison op=
erators for <span style=3D"font-family:courier new,monospace">view</span> a=
nd <span style=3D"font-family:courier new,monospace">optional_view</span> h=
ave pointer-like semantics, while <span style=3D"font-family:courier new,mo=
nospace">std::string_view</span> and the proposed <span style=3D"font-famil=
y:courier new,monospace">std::array_view</span> have comparison operators w=
ith value-/reference-like semantics. I believe this makes the term "vi=
ew" inappropriate in this case.<br><br>I am now trying to think of oth=
er possible names. So far I only have:<br><ul><li><span style=3D"font-famil=
y:courier new,monospace">observer</span> and <span style=3D"font-family:cou=
rier new,monospace">optional_observer</span></li><li><span style=3D"font-fa=
mily:courier new,monospace">indirect</span> and <span style=3D"font-family:=
courier new,monospace">optional_indirect</span></li></ul><p>The term "=
observer" is quite descriptive, but I worry that it implies some imple=
mentation of the observer pattern. The term "indirect" is nice be=
cause it reads quite well grammatically:</p><p><br></p><p></p><div style=3D=
"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-sty=
le:solid;border-width:1px" class=3D"m_-467897888328202192prettyprint"><code=
class=3D"m_-467897888328202192prettyprint"><div class=3D"m_-46789788832820=
2192subprettyprint"><span style=3D"color:#008" class=3D"m_-4678978883282021=
92styled-by-prettify">void</span><span style=3D"color:#000" class=3D"m_-467=
897888328202192styled-by-prettify"> foo</span><span style=3D"color:#660" cl=
ass=3D"m_-467897888328202192styled-by-prettify">(</span><span style=3D"colo=
r:#000" class=3D"m_-467897888328202192styled-by-prettify">indirect</span><s=
pan style=3D"color:#080" class=3D"m_-467897888328202192styled-by-prettify">=
<int></span><span style=3D"color:#000" class=3D"m_-467897888328202192=
styled-by-prettify"> i</span><span style=3D"color:#660" class=3D"m_-4678978=
88328202192styled-by-prettify">);</span><span style=3D"color:#000" class=3D=
"m_-467897888328202192styled-by-prettify"> </span><span style=3D"color:#800=
" class=3D"m_-467897888328202192styled-by-prettify">// function takes an `i=
nt` indirectly</span></div></code></div><p></p><p><br></p><p>And I am aware=
of Jonathan Coe's proposal for a deep-copying smart pointer type calle=
d <span style=3D"font-family:courier new,monospace">indirect</span>, but I =
personally feel a name that describes its deep-copying, pointer-like nature=
would be more appropriate (e.g. its original name, <span style=3D"font-fam=
ily:courier new,monospace">deep_ptr</span>), so I consider the name still u=
p for grabs. And I would also consider <span style=3D"font-family:courier n=
ew,monospace">ref</span> and <span style=3D"font-family:courier new,monospa=
ce">optional_ref</span>, if <span style=3D"font-family:courier new,monospac=
e">std::ref</span> weren't already a factory function for <span style=
=3D"font-family:courier new,monospace">std::reference_wrapper</span>.</p><p=
><br></p><p>I would be interested to hear any other opinions or suggestions=
regarding naming.<br></p><span class=3D""><br>On Wednesday, 16 November 20=
16 14:52:05 UTC+8, <a href=3D"mailto:joseph....@gmail.com" target=3D"_blank=
">joseph....@gmail.com</a> 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 Wednesday, 16 November 2016 12:33:09 UTC+8, Nicol Bola=
s 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"><br><br>O=
n Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, <a>joseph....@gmail.com</=
a> 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 Wednes=
day, 16 November 2016 08:31:16 UTC+8, <a>joseph....@gmail.com</a> wrote:<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">On Wednesday, 16 Nov=
ember 2016 01:38:28 UTC+8, Tony V E wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">So far in the STL "view" also implies re=
ad-only.=C2=A0 "span" implies writable (but also a range, not a s=
ingle).<br></div></blockquote><div><br>AFAIK, string_view is the only "=
;view" currently in the standard, and the rationale in the <span style=
=3D"font-family:courier new,monospace">string_view</span> <a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3762.html" rel=3D"nofoll=
ow" target=3D"_blank">proposal</a> seems to imply that the decision to make=
<a href=3D"http://en.cppreference.com/w/cpp/string/basic_string_view" rel=
=3D"nofollow" target=3D"_blank"><span style=3D"font-family:courier new,mono=
space">basic_string_view</span></a> immutable was specific to that use case=
:<br><ul><li>It's more common to pass strings by reference/pointer-to-c=
onst, so the default (the <span style=3D"font-family:courier new,monospace"=
>string_view</span> type alias) should be immutable. <br></li><ul><li>While=
it is arguably more common to see <span style=3D"font-family:courier new,m=
onospace">T const&</span> than <span style=3D"font-family:courier new,m=
onospace">T&</span>, <span style=3D"font-family:courier new,monospace">=
view</span> and <span style=3D"font-family:courier new,monospace">optional_=
view</span> have no type aliases, so there is no corresponding need to deci=
de a default behaviour.</li></ul><li>You wouldn't be able to change the=
length of a mutable <span style=3D"font-family:courier new,monospace">stri=
ng_view</span> which limits its usefulness.<br></li><ul><li>This is a strin=
g/array-specific problem not shared by <span style=3D"font-family:courier n=
ew,monospace">view</span> and <span style=3D"font-family:courier new,monosp=
ace">optional_view</span>.</li></ul></ul></div></div></blockquote><div>An a=
dditional thought on this. The inability to change the length of a string r=
eferenced by <span style=3D"font-family:courier new,monospace">string_view<=
/span> makes it significantly less useful because strings are not usually t=
hought of as simple arrays of characters: for example, you would expect to =
be able to change <span style=3D"font-family:courier new,monospace">"h=
ello"</span> to <span style=3D"font-family:courier new,monospace">&quo=
t;hello, world"</span> just as easily as to <span style=3D"font-family=
:courier new,monospace">"world"</span>, despite the fact that the=
former is longer than the original string. Conversely, the ability to add =
extra elements to an <span style=3D"font-family:courier new,monospace">arra=
y_view</span> is not required for it to be useful; indeed, <span style=3D"f=
ont-family:courier new,monospace">std::array</span> has a fixed length, whi=
le there is no fixed length version of <span style=3D"font-family:courier n=
ew,monospace">std::string</span>. Thus, it seems extremely likely to me tha=
t <span style=3D"font-family:courier new,monospace">std::array_view</span> =
<i>would</i> support the mutable use case just as <span style=3D"font-famil=
y:courier new,monospace">gsl::span</span> does.<br></div></div></blockquote=
><div><br>And yet, <a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fww=
w.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2012%2Fn3334.html&=
;sa=3DD&sntz=3D1&usg=3DAFQjCNG_ttOUsXVKaIvFFZ_1Xh8wEaxJwQ" rel=3D"n=
ofollow" target=3D"_blank">the original proposed array_ref</a> did not supp=
ort mutable arrays.</div></div></blockquote><div><br>Perhaps opinion has sh=
ifted since then, because it seems that more recent proposals do:<br><ul><l=
i><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.=
html" rel=3D"nofollow" target=3D"_blank">Multidimensional bounds, <span sty=
le=3D"font-family:courier new,monospace">offset</span> and <span style=3D"f=
ont-family:courier new,monospace">arra</span></a><a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2015/n4512.html" rel=3D"nofollow" targe=
t=3D"_blank"><span style=3D"font-family:courier new,monospace">y_view</span=
>, revision 7</a> (2015-05-07)</li><li><a href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2015/p0122r0.pdf" rel=3D"nofollow" target=3D"_bla=
nk"><span style=3D"font-family:courier new,monospace">array_view</span>: bo=
unds-safe views for sequences of objects</a> (2015-09-25)</li></ul></div></=
div></blockquote></span></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<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/c62241d5-0e3d-4925-965f-e84d6a2631a0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/c622=
41d5-0e3d-4925-<wbr>965f-e84d6a2631a0%40isocpp.org</a><wbr>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<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" 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/CAOHCbiub3y%2Baejg9dkW%3DicGkvRk%2Bw_=
qQ%2BKAfK3weCR3U7Dyyvw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiub=
3y%2Baejg9dkW%3DicGkvRk%2Bw_qQ%2BKAfK3weCR3U7Dyyvw%40mail.gmail.com</a>.<br=
/>
--089e013c6b2aa0c8e00541ac2a0a--
.
Author: Joseph Thomson <joseph.thomson@gmail.com>
Date: Sun, 20 Nov 2016 09:55:50 +0800
Raw View
--001a11472dc4bfdacc0541b1d6a5
Content-Type: text/plain; charset=UTF-8
On 20 Nov 2016 03:09, "Tony V E" <tvaneerd@gmail.com> wrote:
>
> Jonathan's class was recently changed to polymorphic_value. (And/or
clone_ptr if it gets split into 2 classes)
Great. That's exactly what I was suggesting in the discussion thread.
Perhaps I'll go with `indirect` for now, unless anyone can suggest
something better. I'm probably going to start drawing up a formal proposal
since no one seems to have much feedback.
> On Sat, Nov 19, 2016 at 11:30 AM, <joseph.thomson@gmail.com> wrote:
>>
>> It has just occurred to me that "view" may not be appropriate for
another reason. The comparison operators for view and optional_view have
pointer-like semantics, while std::string_view and the proposed
std::array_view have comparison operators with value-/reference-like
semantics. I believe this makes the term "view" inappropriate in this case.
>>
>> I am now trying to think of other possible names. So far I only have:
>> observer and optional_observer
>> indirect and optional_indirect
>>
>> The term "observer" is quite descriptive, but I worry that it implies
some implementation of the observer pattern. The term "indirect" is nice
because it reads quite well grammatically:
>>
>>
>> void foo(indirect<int> i); // function takes an `int` indirectly
>>
>>
>> And I am aware of Jonathan Coe's proposal for a deep-copying smart
pointer type called indirect, but I personally feel a name that describes
its deep-copying, pointer-like nature would be more appropriate (e.g. its
original name, deep_ptr), so I consider the name still up for grabs. And I
would also consider ref and optional_ref, if std::ref weren't already a
factory function for std::reference_wrapper.
>>
>>
>> I would be interested to hear any other opinions or suggestions
regarding naming.
>>
>>
>> On Wednesday, 16 November 2016 14:52:05 UTC+8, joseph....@gmail.com
wrote:
>>>
>>> On Wednesday, 16 November 2016 12:33:09 UTC+8, Nicol Bolas wrote:
>>>>
>>>>
>>>>
>>>> On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, joseph....@gmail.com
wrote:
>>>>>
>>>>> On Wednesday, 16 November 2016 08:31:16 UTC+8, joseph....@gmail.com
wrote:
>>>>>>
>>>>>> On Wednesday, 16 November 2016 01:38:28 UTC+8, Tony V E wrote:
>>>>>>>
>>>>>>> So far in the STL "view" also implies read-only. "span" implies
writable (but also a range, not a single).
>>>>>>
>>>>>>
>>>>>> AFAIK, string_view is the only "view" currently in the standard, and
the rationale in the string_view proposal seems to imply that the decision
to make basic_string_view immutable was specific to that use case:
>>>>>> It's more common to pass strings by reference/pointer-to-const, so
the default (the string_view type alias) should be immutable.
>>>>>> While it is arguably more common to see T const& than T&, view and
optional_view have no type aliases, so there is no corresponding need to
decide a default behaviour.
>>>>>> You wouldn't be able to change the length of a mutable string_view
which limits its usefulness.
>>>>>> This is a string/array-specific problem not shared by view and
optional_view.
>>>>>
>>>>> An additional thought on this. The inability to change the length of
a string referenced by string_view makes it significantly less useful
because strings are not usually thought of as simple arrays of characters:
for example, you would expect to be able to change "hello" to "hello,
world" just as easily as to "world", despite the fact that the former is
longer than the original string. Conversely, the ability to add extra
elements to an array_view is not required for it to be useful; indeed,
std::array has a fixed length, while there is no fixed length version of
std::string. Thus, it seems extremely likely to me that std::array_view
would support the mutable use case just as gsl::span does.
>>>>
>>>>
>>>> And yet, the original proposed array_ref did not support mutable
arrays.
>>>
>>>
>>> Perhaps opinion has shifted since then, because it seems that more
recent proposals do:
>>> Multidimensional bounds, offset and array_view, revision 7 (2015-05-07)
>>> array_view: bounds-safe views for sequences of objects (2015-09-25)
>>
>> --
>> 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/c62241d5-0e3d-4925-965f-e84d6a2631a0%40isocpp.org
..
>
>
>
>
> --
> Be seeing you,
> Tony
>
> --
> You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0/unsubscribe
..
> To unsubscribe from this group and all its topics, 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/CAOHCbiub3y%2Baejg9dkW%3DicGkvRk%2Bw_qQ%2BKAfK3weCR3U7Dyyvw%40mail.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/CAHocnE-sk85uHw9L1SS%3DX1QWXVnwWNZBNECDa%3D2tHS64JWGTOQ%40mail.gmail.com.
--001a11472dc4bfdacc0541b1d6a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">On 20 Nov 2016 03:09, "Tony V E" <<a href=3D"ma=
ilto:tvaneerd@gmail.com">tvaneerd@gmail.com</a>> wrote:<br>
><br>
> Jonathan's class was recently changed to polymorphic_value. (And/o=
r clone_ptr if it gets split into 2 classes)</p>
<p dir=3D"ltr">Great. That's exactly what I was suggesting in the discu=
ssion thread. Perhaps I'll go with `indirect` for now, unless anyone ca=
n suggest something better. I'm probably going to start drawing up a fo=
rmal proposal since no one seems to have much feedback.</p>
<p dir=3D"ltr">> On Sat, Nov 19, 2016 at 11:30 AM, <<a href=3D"mailto=
:joseph.thomson@gmail.com">joseph.thomson@gmail.com</a>> wrote:<br>
>><br>
>> It has just occurred to me that "view" may not be approp=
riate for another reason. The comparison operators for view and optional_vi=
ew have pointer-like semantics, while std::string_view and the proposed std=
::array_view have comparison operators with value-/reference-like semantics=
.. I believe this makes the term "view" inappropriate in this case=
..<br>
>><br>
>> I am now trying to think of other possible names. So far I only ha=
ve:<br>
>> observer and optional_observer<br>
>> indirect and optional_indirect<br>
>><br>
>> The term "observer" is quite descriptive, but I worry th=
at it implies some implementation of the observer pattern. The term "i=
ndirect" is nice because it reads quite well grammatically:<br>
>><br>
>><br>
>> void foo(indirect<int> i); // function takes an `int` indire=
ctly<br>
>><br>
>><br>
>> And I am aware of Jonathan Coe's proposal for a deep-copying s=
mart pointer type called indirect, but I personally feel a name that descri=
bes its deep-copying, pointer-like nature would be more appropriate (e.g. i=
ts original name, deep_ptr), so I consider the name still up for grabs. And=
I would also consider ref and optional_ref, if std::ref weren't alread=
y a factory function for std::reference_wrapper.<br>
>><br>
>><br>
>> I would be interested to hear any other opinions or suggestions re=
garding naming.<br>
>><br>
>><br>
>> On Wednesday, 16 November 2016 14:52:05 UTC+8, <a href=3D"mailto:j=
oseph....@gmail.com">joseph....@gmail.com</a> wrote:<br>
>>><br>
>>> On Wednesday, 16 November 2016 12:33:09 UTC+8, Nicol Bolas wro=
te:<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tuesday, November 15, 2016 at 7:57:31 PM UTC-5, <a href=
=3D"mailto:joseph....@gmail.com">joseph....@gmail.com</a> wrote:<br>
>>>>><br>
>>>>> On Wednesday, 16 November 2016 08:31:16 UTC+8, <a href=
=3D"mailto:joseph....@gmail.com">joseph....@gmail.com</a> wrote:<br>
>>>>>><br>
>>>>>> On Wednesday, 16 November 2016 01:38:28 UTC+8, Ton=
y V E wrote:<br>
>>>>>>><br>
>>>>>>> So far in the STL "view" also implie=
s read-only.=C2=A0 "span" implies writable (but also a range, not=
a single).<br>
>>>>>><br>
>>>>>><br>
>>>>>> AFAIK, string_view is the only "view" cu=
rrently in the standard, and the rationale in the string_view proposal seem=
s to imply that the decision to make basic_string_view immutable was specif=
ic to that use case:<br>
>>>>>> It's more common to pass strings by reference/=
pointer-to-const, so the default (the string_view type alias) should be imm=
utable. <br>
>>>>>> While it is arguably more common to see T const&am=
p; than T&, view and optional_view have no type aliases, so there is no=
corresponding need to decide a default behaviour.<br>
>>>>>> You wouldn't be able to change the length of a=
mutable string_view which limits its usefulness.<br>
>>>>>> This is a string/array-specific problem not shared=
by view and optional_view.<br>
>>>>><br>
>>>>> An additional thought on this. The inability to change=
the length of a string referenced by string_view makes it significantly le=
ss useful because strings are not usually thought of as simple arrays of ch=
aracters: for example, you would expect to be able to change "hello&qu=
ot; to "hello, world" just as easily as to "world", des=
pite the fact that the former is longer than the original string. Conversel=
y, the ability to add extra elements to an array_view is not required for i=
t to be useful; indeed, std::array has a fixed length, while there is no fi=
xed length version of std::string. Thus, it seems extremely likely to me th=
at std::array_view would support the mutable use case just as gsl::span doe=
s.<br>
>>>><br>
>>>><br>
>>>> And yet, the original proposed array_ref did not support m=
utable arrays.<br>
>>><br>
>>><br>
>>> Perhaps opinion has shifted since then, because it seems that =
more recent proposals do:<br>
>>> Multidimensional bounds, offset and array_view, revision 7 (20=
15-05-07)<br>
>>> array_view: bounds-safe views for sequences of objects (2015-0=
9-25)<br>
>><br>
>> -- <br>
>> You received this message because you are subscribed to the Google=
Groups "ISO C++ Standard - Future Proposals" group.<br>
>> To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">=
std-proposals+unsubscribe@isocpp.org</a>.<br>
>><br>
>> To post to this group, send email to <a href=3D"mailto:std-proposa=
ls@isocpp.org">std-proposals@isocpp.org</a>.<br>
>> To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/c62241d5-0e3d-4925-965f-e84d=
6a2631a0%40isocpp.org">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/c62241d5-0e3d-4925-965f-e84d6a2631a0%40isocpp.org</a>.<br>
><br>
><br>
><br>
><br>
> -- <br>
> Be seeing you,<br>
> Tony<br>
><br>
> -- <br>
> You received this message because you are subscribed to a topic in the=
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0/unsubscribe">https://gr=
oups.google.com/a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0/unsubscribe<=
/a>.<br>
> To unsubscribe from this group and all its topics, send an email to <a=
href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsub=
scribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> To view this discussion on the web visit <a href=3D"https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiub3y%2Baejg9dkW%3DicGkvRk=
%2Bw_qQ%2BKAfK3weCR3U7Dyyvw%40mail.gmail.com">https://groups.google.com/a/i=
socpp.org/d/msgid/std-proposals/CAOHCbiub3y%2Baejg9dkW%3DicGkvRk%2Bw_qQ%2BK=
AfK3weCR3U7Dyyvw%40mail.gmail.com</a>.<br></p>
<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/CAHocnE-sk85uHw9L1SS%3DX1QWXVnwWNZBNE=
CDa%3D2tHS64JWGTOQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHocnE-sk85u=
Hw9L1SS%3DX1QWXVnwWNZBNECDa%3D2tHS64JWGTOQ%40mail.gmail.com</a>.<br />
--001a11472dc4bfdacc0541b1d6a5--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 20 Nov 2016 22:30:42 +0100
Raw View
This is a multi-part message in MIME format.
--------------903C88E999E9AFFB4998DCE5
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit :
>
> On 20 Nov 2016 03:09, "Tony V E" <tvaneerd@gmail.com=20
> <mailto:tvaneerd@gmail.com>> wrote:
> >
> > Jonathan's class was recently changed to polymorphic_value. (And/or=20
> clone_ptr if it gets split into 2 classes)
>
> Great. That's exactly what I was suggesting in the discussion thread.=20
> Perhaps I'll go with `indirect` for now, unless anyone can suggest=20
> something better. I'm probably going to start drawing up a formal=20
> proposal since no one seems to have much feedback.
>
What about letting the current std::reference_wrapper do that?
std::reference_wrapper behaves already like a function objet when the=20
reference variable is a function object. Adding pointer (reference)=20
semantics seems quite appropriated to me (at least until we have=20
operator dot).
Would optional_view<T> behave differently than optional<view<T>>? If=20
yes, when and why?
Vicente
--=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/36b326d8-ae0c-499c-9032-5b0e91c7ef71%40wanadoo.f=
r.
--------------903C88E999E9AFFB4998DCE5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 20/11/2016 =C3=A0 02:55, Joseph Thoms=
on a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:CAHocnE-sk85uHw9L1SS=3DX1QWXVnwWNZBNECDa=3D2tHS64JWGTOQ@mail.gm=
ail.com"
type=3D"cite">
<p dir=3D"ltr">On 20 Nov 2016 03:09, "Tony V E" <<a
moz-do-not-send=3D"true" href=3D"mailto:tvaneerd@gmail.com">tvane=
erd@gmail.com</a>>
wrote:<br>
><br>
> Jonathan's class was recently changed to polymorphic_value.
(And/or clone_ptr if it gets split into 2 classes)</p>
<p dir=3D"ltr">Great. That's exactly what I was suggesting in the
discussion thread. Perhaps I'll go with `indirect` for now,
unless anyone can suggest something better. I'm probably going
to start drawing up a formal proposal since no one seems to have
much feedback.</p>
</blockquote>
<br>
What about letting the current std::reference_wrapper do that?<br>
std::reference_wrapper behaves already like a function objet when
the reference variable is a function object. Adding pointer
(reference) semantics seems quite appropriated to me (at least until
we have operator dot).<br>
<br>
Would optional_view<T> behave differently than
optional<view<T>>? If yes, when and why?<br>
<br>
Vicente<br>
</body>
</html>
<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/36b326d8-ae0c-499c-9032-5b0e91c7ef71%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36b326d8-ae0c-499c-9032-5b0e91c7ef71=
%40wanadoo.fr</a>.<br />
--------------903C88E999E9AFFB4998DCE5--
.
Author: joseph.thomson@gmail.com
Date: Sun, 20 Nov 2016 17:26:02 -0800 (PST)
Raw View
------=_Part_5063_163675096.1479691562663
Content-Type: multipart/alternative;
boundary="----=_Part_5064_1593679743.1479691562664"
------=_Part_5064_1593679743.1479691562664
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, 21 November 2016 05:30:45 UTC+8, Vicente J. Botet Escriba wrote:
>
> Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit :
>
> On 20 Nov 2016 03:09, "Tony V E" <tvan...@gmail.com <javascript:>> wrote:
> >
> > Jonathan's class was recently changed to polymorphic_value. (And/or=20
> clone_ptr if it gets split into 2 classes)
>
> Great. That's exactly what I was suggesting in the discussion thread.=20
> Perhaps I'll go with `indirect` for now, unless anyone can suggest=20
> something better. I'm probably going to start drawing up a formal proposa=
l=20
> since no one seems to have much feedback.
>
>
> What about letting the current std::reference_wrapper do that?
> std::reference_wrapper behaves already like a function objet when the=20
> reference variable is a function object. Adding pointer (reference)=20
> semantics seems quite appropriated to me (at least until we have operator=
=20
> dot).
>
I'm not completely sure what you're suggesting. std::reference_wrapper<T>=
=20
has mostly reference-like semantics, except for its pointer-like copy=20
construction and assignment semantics. indirect<T> and optional_indirect<T>=
=20
(I'm calling them that from now on) have mostly pointer-like semantics,=20
except for their reference-like construction semantics; they also have a=20
much narrower interface than pointers (e.g. no pointer arithmetic) which=20
makes them a lot easier to use correctly as non-owning indirection types.
If you are having a hard time understanding the difference, it's probably=
=20
best to consider equality comparison:
int i =3D {};
int j =3D {};
reference_wrapper<int> rw =3D i;
assert(rw =3D=3D j); // passes
indirect<int> in =3D i;
assert(in !=3D j); // passes
reference_wrapper tests equal if the underlying *value* is equal, like=20
references; indirect and optional_indirect test equal if they point to the=
=20
same object. This is the distinction between *value* and *identity*.
Would optional_view<T> behave differently than optional<view<T>>? If yes,=
=20
> when and why?
>
> Vicente=20
>
They are mostly functionally equivalent. As far as I can tell,=20
optional_indirect offers two advantages:
1. optional<indirect<T>> *probably* occupies twice as much memory as=20
optional_indirect<T>, because the former needs to store a flag=20
indicating whether it contains a value, while the latter uses the null=
=20
pointer state to indicate emptiness. If optional_indirect didn't exist,=
=20
some people may not use optional<indirect<T>> just to avoid the=20
additional memory cost compared to T*.
2. There are situations when you have to dereference (*) an=20
optional<indirect<T>> but not an optional_indirect<T>, most=20
significantly when calling indirect::operator* or indirect::operator->.=
=20
This is a syntactic nuisance. Compare this:
foo f;
optional<indirect<foo>> o =3D f;
(*o)->bar =3D 42;
o.value()->bar =3D 42;
foo* p =3D static_cast<foo*>(*o);
with this:
foo f;
optional_indirect<foo> o =3D f;
o->bar =3D 42;
o.value().bar =3D 42;
foo* p =3D static_cast<foo*>(o);
--=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/f28ccd07-e796-4abc-a5f1-e800b4ba3be5%40isocpp.or=
g.
------=_Part_5064_1593679743.1479691562664
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, 21 November 2016 05:30:45 UTC+8, Vicent=
e J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div>
<div>Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<p dir=3D"ltr">On 20 Nov 2016 03:09, "Tony V E" <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Ag-1OmSEAgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">tvan...@gmai=
l.com</a>>
wrote:<br>
><br>
> Jonathan's class was recently changed to polymorphic_value=
..
(And/or clone_ptr if it gets split into 2 classes)</p>
<p dir=3D"ltr">Great. That's exactly what I was suggesting in the
discussion thread. Perhaps I'll go with `indirect` for now,
unless anyone can suggest something better. I'm probably going
to start drawing up a formal proposal since no one seems to have
much feedback.</p>
</blockquote>
<br>
What about letting the current std::reference_wrapper do that?<br>
std::reference_wrapper behaves already like a function objet when
the reference variable is a function object. Adding pointer
(reference) semantics seems quite appropriated to me (at least until
we have operator dot).<br></div></blockquote><div><br>I'm not compl=
etely sure what you're suggesting. <span style=3D"font-family: courier =
new,monospace;">std::reference_wrapper<T></span> has mostly reference=
-like semantics, except for its pointer-like copy construction and assignme=
nt semantics. <span style=3D"font-family: courier new,monospace;">indirect&=
lt;T></span> and <span style=3D"font-family: courier new,monospace;">opt=
ional_indirect<T></span> (I'm calling them that from now on) have=
mostly pointer-like semantics, except for their reference-like constructio=
n semantics; they also have a much narrower interface than pointers (e.g. n=
o pointer arithmetic) which makes them a lot easier to use correctly as non=
-owning indirection types.<br><br>If you are having a hard time understandi=
ng the difference, it's probably best to consider equality comparison:<=
br><br><span style=3D"font-family: courier new,monospace;">int i =3D {};<br=
>int j =3D {};<br><br>reference_wrapper<int> rw =3D i;<br>assert(rw =
=3D=3D j); // passes<br><br>indirect<int> in =3D i;<br>assert(in !=3D=
j); // passes</span><br><br><span style=3D"font-family: courier new,monosp=
ace;">reference_wrapper</span> tests equal if the underlying <i>value</i> i=
s equal, like references; <span style=3D"font-family: courier new,monospace=
;">indirect</span> and <span style=3D"font-family: courier new,monospace;">=
optional_indirect</span> test equal if they point to the same object. This =
is the distinction between <i>value</i> and <i>identity</i>.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div>
Would optional_view<T> behave differently than
optional<view<T>>? If yes, when and why?<br>
<br>
Vicente <br></div></blockquote><div><br>They are mostly functionally eq=
uivalent. As far as I can tell, <span style=3D"font-family: courier new,mon=
ospace;">optional_indirect</span> offers two advantages:<br><ol><li><span s=
tyle=3D"font-family: courier new,monospace;">optional<indirect<T>&=
gt;</span> <i>probably</i> occupies twice as much memory as <span style=3D"=
font-family: courier new,monospace;">optional_indirect<T></span>, bec=
ause the former needs to store a flag indicating whether it contains a valu=
e, while the latter uses the null pointer state to indicate emptiness. If <=
span style=3D"font-family: courier new,monospace;">optional_indirect</span>=
didn't exist, some people may not use <span style=3D"font-family: cour=
ier new,monospace;">optional<indirect<T>></span> just to avoid =
the additional memory cost compared to <span style=3D"font-family: courier =
new,monospace;">T*</span>.<br></li><li>There are situations when you have t=
o dereference (<span style=3D"font-family: courier new,monospace;">*</span>=
) an <span style=3D"font-family: courier new,monospace;">optional<indire=
ct<T>></span> but not an <span style=3D"font-family: courier new,m=
onospace;">optional_indirect<T></span>, most significantly when calli=
ng <span style=3D"font-family: courier new,monospace;">indirect::operator*<=
/span> or <span style=3D"font-family: courier new,monospace;">indirect::ope=
rator-></span>. This is a syntactic nuisance. Compare this:</li></ol><di=
v style=3D"margin-left: 40px;"><div style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">foo f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>optional</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">indirect</span><span style=3D"color: #080;" class=3D"styled-by-pretti=
fy"><foo></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
o </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><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"><br></span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(*</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">o</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">)-></span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">bar </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">42</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>o</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">value</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">()-></span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">bar </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">42</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>foo</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> p </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">static_cast</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify"><</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">foo</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*>(*</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">o</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span></div></code></div></div><br><p style=3D"margin-left: 40px;=
">with this:</p><p style=3D"margin-left: 40px;"><br></p><p style=3D"margin-=
left: 40px;"></p><div style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflo=
w-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div=
class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">foo f</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>o=
ptional_indirect</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify"><foo></span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> o </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>o</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">-></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">bar </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">42</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>o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">value</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">().</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">bar </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">42</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>foo</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">*</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> p </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">foo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">*>(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">o</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">);</span></div></code></div><p></p><p style=
=3D"margin-left: 40px;"><br></p></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/f28ccd07-e796-4abc-a5f1-e800b4ba3be5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f28ccd07-e796-4abc-a5f1-e800b4ba3be5=
%40isocpp.org</a>.<br />
------=_Part_5064_1593679743.1479691562664--
------=_Part_5063_163675096.1479691562663--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 21 Nov 2016 20:00:30 +0100
Raw View
This is a multi-part message in MIME format.
--------------D0DAC2BC24025ACBD598CB6D
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 21/11/2016 =C3=A0 02:26, joseph.thomson@gmail.com a =C3=A9crit :
>
>
> On Monday, 21 November 2016 05:30:45 UTC+8, Vicente J. Botet Escriba=20
> wrote:
>
> Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit :
>>
>> On 20 Nov 2016 03:09, "Tony V E" <tvan...@gmail.com
>> <javascript:>> wrote:
>> >
>> > Jonathan's class was recently changed to polymorphic_value.
>> (And/or clone_ptr if it gets split into 2 classes)
>>
>> Great. That's exactly what I was suggesting in the discussion
>> thread. Perhaps I'll go with `indirect` for now, unless anyone
>> can suggest something better. I'm probably going to start drawing
>> up a formal proposal since no one seems to have much feedback.
>>
>
> What about letting the current std::reference_wrapper do that?
> std::reference_wrapper behaves already like a function objet when
> the reference variable is a function object. Adding pointer
> (reference) semantics seems quite appropriated to me (at least
> until we have operator dot).
>
>
> I'm not completely sure what you're suggesting.=20
> std::reference_wrapper<T> has mostly reference-like semantics, except=20
> for its pointer-like copy construction and assignment semantics.=20
> indirect<T> and optional_indirect<T> (I'm calling them that from now=20
> on) have mostly pointer-like semantics, except for their=20
> reference-like construction semantics; they also have a much narrower=20
> interface than pointers (e.g. no pointer arithmetic) which makes them=20
> a lot easier to use correctly as non-owning indirection types.
>
> If you are having a hard time understanding the difference, it's=20
> probably best to consider equality comparison:
>
> int i =3D {};
> int j =3D {};
>
> reference_wrapper<int> rw =3D i;
> assert(rw =3D=3D j); // passes
>
> indirect<int> in =3D i;
> assert(in !=3D j); // passes
>
> reference_wrapper tests equal if the underlying /value/ is equal, like=20
> references; indirect and optional_indirect test equal if they point to=20
> the same object. This is the distinction between /value/ and /identity/.
Oh, I didn't saw you wanted pointer semantics. I didn't notice either=20
that the link contents was changed since the first post.
Why don't you reuse observer_ptr then? Do we really need two classes=20
because the way they are initialized? Why not update the interface if we=20
consider it is useful?
I agree that a not owning pointer should be initializable from a=20
reference. Are there other differences?
Should indirect<T> behave like an hypothetical=20
not_null<observer_ptr<T>>? or just not_null<T*>? Note that I'm talking=20
here of an hypothetical std::not_null class, not the gsl;;not_null.
>
> Would optional_view<T> behave differently than optional<view<T>>?
> If yes, when and why?
>
>
>
> They are mostly functionally equivalent. As far as I can tell,=20
> optional_indirect offers two advantages:
>
> 1. optional<indirect<T>> /probably/ occupies twice as much memory as
> optional_indirect<T>, because the former needs to store a flag
> indicating whether it contains a value, while the latter uses the
> null pointer state to indicate emptiness. If optional_indirect
> didn't exist, some people may not use optional<indirect<T>> just
> to avoid the additional memory cost compared to T*.
>
We could have a specialization that preserves the interface and improves=20
the space performances, isn't it?
I don't know how the committee fills about specializations like this one.
> 1. There are situations when you have to dereference (*) an
> optional<indirect<T>> but not an optional_indirect<T>, most
> significantly when calling indirect::operator* or
> indirect::operator->. This is a syntactic nuisance. Compare this:
>
> |
> foo f;
> optional<indirect<foo>>o =3Df;
> (*o)->bar =3D42;
> |
|You could use here |o->bar also
> |
> o.value()->bar =3D42;
> foo*p =3Dstatic_cast<foo*>(*o);
> |
>
> with this:
>
>
> |
> foo f;
> optional_indirect<foo>o =3Df;
> o->bar =3D42;
> o.value().bar =3D42;
> foo*p =3Dstatic_cast<foo*>(o);
> |
>
>
I'm not sure yet to want two new class for just these differences, but I=20
can change.
I believe it is worth seen how a better observer_ptr and an orthogonal=20
not_null wrapper behave together.
Vicente
--=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/60f5b2af-99cc-7cfa-a123-617de4f2f274%40wanadoo.f=
r.
--------------D0DAC2BC24025ACBD598CB6D
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 21/11/2016 =C3=A0 02:26,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:joseph.thomson@g=
mail.com">joseph.thomson@gmail.com</a> a =C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:f28ccd07-e796-4abc-a5f1-e800b4ba3be5@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Monday, 21 November 2016 05:30:45 UTC+8, Vicente J. Botet
Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div>
<div>Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit=C2=
=A0:<br>
</div>
<blockquote type=3D"cite">
<p dir=3D"ltr">On 20 Nov 2016 03:09, "Tony V E" <<a
moz-do-not-send=3D"true" href=3D"javascript:"
target=3D"_blank" gdf-obfuscated-mailto=3D"Ag-1OmSEAgAJ"
rel=3D"nofollow"
onmousedown=3D"this.href=3D'javascript:';return true;"
onclick=3D"this.href=3D'javascript:';return true;">tvan..=
..@gmail.com</a>>
wrote:<br>
><br>
> Jonathan's class was recently changed to
polymorphic_value. (And/or clone_ptr if it gets split
into 2 classes)</p>
<p dir=3D"ltr">Great. That's exactly what I was suggesting
in the discussion thread. Perhaps I'll go with
`indirect` for now, unless anyone can suggest something
better. I'm probably going to start drawing up a formal
proposal since no one seems to have much feedback.</p>
</blockquote>
<br>
What about letting the current std::reference_wrapper do
that?<br>
std::reference_wrapper behaves already like a function objet
when the reference variable is a function object. Adding
pointer (reference) semantics seems quite appropriated to me
(at least until we have operator dot).<br>
</div>
</blockquote>
<div><br>
I'm not completely sure what you're suggesting. <span
style=3D"font-family: courier new,monospace;">std::reference_wr=
apper<T></span>
has mostly reference-like semantics, except for its
pointer-like copy construction and assignment semantics. <span
style=3D"font-family: courier new,monospace;">indirect<T>=
</span>
and <span style=3D"font-family: courier new,monospace;">optional_=
indirect<T></span>
(I'm calling them that from now on) have mostly pointer-like
semantics, except for their reference-like construction
semantics; they also have a much narrower interface than
pointers (e.g. no pointer arithmetic) which makes them a lot
easier to use correctly as non-owning indirection types.<br>
<br>
If you are having a hard time understanding the difference,
it's probably best to consider equality comparison:<br>
<br>
<span style=3D"font-family: courier new,monospace;">int i =3D {};=
<br>
int j =3D {};<br>
<br>
reference_wrapper<int> rw =3D i;<br>
assert(rw =3D=3D j); // passes<br>
<br>
indirect<int> in =3D i;<br>
assert(in !=3D j); // passes</span><br>
<br>
<span style=3D"font-family: courier new,monospace;">reference_wra=
pper</span>
tests equal if the underlying <i>value</i> is equal, like
references; <span style=3D"font-family: courier new,monospace;">i=
ndirect</span>
and <span style=3D"font-family: courier new,monospace;">optional_=
indirect</span>
test equal if they point to the same object. This is the
distinction between <i>value</i> and <i>identity</i>.<br>
</div>
</div>
</blockquote>
Oh, I didn't saw you wanted pointer semantics. I didn't notice
either that the link contents was changed since the first post.<br>
<br>
<br>
<br>
Why don't you reuse observer_ptr then? Do we really need two classes
because the way they are initialized? Why not update the interface
if we consider it is useful? <br>
I agree that a not owning pointer should be initializable from a
reference. Are there other differences?<br>
<br>
Should indirect<T> behave like an hypothetical
not_null<observer_ptr<T>>? or just not_null<T*>?
Note that I'm talking here of an hypothetical std::not_null class,
not the gsl;;not_null.<br>
<br>
<blockquote
cite=3D"mid:f28ccd07-e796-4abc-a5f1-e800b4ba3be5@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<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> Would optional_view<T> behave differently than
optional<view<T>>? If yes, when and why?<br>
<br>
<br>
</div>
</blockquote>
<div><br>
They are mostly functionally equivalent. As far as I can tell,
<span style=3D"font-family: courier new,monospace;">optional_indi=
rect</span>
offers two advantages:<br>
<ol>
<li><span style=3D"font-family: courier new,monospace;">optiona=
l<indirect<T>></span>
<i>probably</i> occupies twice as much memory as <span
style=3D"font-family: courier new,monospace;">optional_indi=
rect<T></span>,
because the former needs to store a flag indicating
whether it contains a value, while the latter uses the
null pointer state to indicate emptiness. If <span
style=3D"font-family: courier new,monospace;">optional_indi=
rect</span>
didn't exist, some people may not use <span
style=3D"font-family: courier new,monospace;">optional<i=
ndirect<T>></span>
just to avoid the additional memory cost compared to <span
style=3D"font-family: courier new,monospace;">T*</span>.<br=
>
</li>
</ol>
</div>
</div>
</blockquote>
We could have a specialization that preserves the interface and
improves the space performances, isn't it?<br>
I don't know how the committee fills about specializations like this
one. <br>
=C2=A0<br>
<blockquote
cite=3D"mid:f28ccd07-e796-4abc-a5f1-e800b4ba3be5@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<ol>
<li>There are situations when you have to dereference (<span
style=3D"font-family: courier new,monospace;">*</span>) an
<span style=3D"font-family: courier new,monospace;">optional&=
lt;indirect<T>></span>
but not an <span style=3D"font-family: courier
new,monospace;">optional_indirect<T></span>, most
significantly when calling <span style=3D"font-family:
courier new,monospace;">indirect::operator*</span> or <span
style=3D"font-family: courier new,monospace;">indirect::ope=
rator-></span>.
This is a syntactic nuisance. Compare this:</li>
</ol>
<div style=3D"margin-left: 40px;">
<div style=3D"background-color: rgb(250, 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">foo f</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>
optional</span><span style=3D"color: #660;"
class=3D"styled-by-prettify"><</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">ind=
irect</span><span
style=3D"color: #080;" class=3D"styled-by-prettify"><=
;foo></span><span
style=3D"color: #660;" class=3D"styled-by-prettify">>=
;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> o =
</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</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"><br=
>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(*</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">o</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">)-&=
gt;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">bar
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">=3D</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span
style=3D"color: #066;" class=3D"styled-by-prettify">42<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>
</span></div>
</code></div>
</div>
</div>
</div>
</blockquote>
<code>You could use here </code>o->bar also<br>
<blockquote
cite=3D"mid:f28ccd07-e796-4abc-a5f1-e800b4ba3be5@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>
<div style=3D"margin-left: 40px;">
<div style=3D"background-color: rgb(250, 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">o</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify">val=
ue</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">()-=
></span><span
style=3D"color: #000;" class=3D"styled-by-prettify">bar
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">=3D</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span
style=3D"color: #066;" class=3D"styled-by-prettify">42<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>
foo</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">*</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> p =
</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span
style=3D"color: #008;" class=3D"styled-by-prettify">sta=
tic_cast</span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><=
;</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">foo=
</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">*&g=
t;(*</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">o</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span></div>
</code></div>
</div>
<br>
<p style=3D"margin-left: 40px;">with this:</p>
<p style=3D"margin-left: 40px;"><br>
</p>
<div style=3D"background-color: rgb(250, 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">foo f</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
optional_indirect</span><span style=3D"color: #080;"
class=3D"styled-by-prettify"><foo></span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> o </=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> f</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
o</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">-></span><span
style=3D"color: #000;" class=3D"styled-by-prettify">bar <=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #066;" class=3D"styled-by-prettify">42</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
o</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">.</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify">value</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">().</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify">bar <=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #066;" class=3D"styled-by-prettify">42</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
foo</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">*</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"> p </span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #008;" class=3D"styled-by-prettify">stati=
c_cast</span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify">foo</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">*>=
(</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">o</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">);</s=
pan></div>
</code></div>
<p style=3D"margin-left: 40px;"><br>
</p>
</div>
</div>
</blockquote>
I'm not sure yet to want two new class for just these differences,
but I can change.<br>
I believe it is worth seen how a better observer_ptr and an
orthogonal not_null wrapper behave together.<br>
<br>
Vicente<br>
<br>
</body>
</html>
<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/60f5b2af-99cc-7cfa-a123-617de4f2f274%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/60f5b2af-99cc-7cfa-a123-617de4f2f274=
%40wanadoo.fr</a>.<br />
--------------D0DAC2BC24025ACBD598CB6D--
.
Author: joseph.thomson@gmail.com
Date: Mon, 21 Nov 2016 18:24:34 -0800 (PST)
Raw View
------=_Part_8679_230267797.1479781475003
Content-Type: multipart/alternative;
boundary="----=_Part_8680_166659439.1479781475004"
------=_Part_8680_166659439.1479781475004
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, Nov 22, 2016 at 3:00 AM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 21/11/2016 =C3=A0 02:26, joseph.thomson@gmail.com a =C3=A9crit :
>
>
>
> On Monday, 21 November 2016 05:30:45 UTC+8, Vicente J. Botet Escriba=20
> wrote:=20
>>
>> Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit :
>>
>> On 20 Nov 2016 03:09, "Tony V E" <tvan...@gmail.com> wrote:
>> >
>> > Jonathan's class was recently changed to polymorphic_value. (And/or=20
>> clone_ptr if it gets split into 2 classes)
>>
>> Great. That's exactly what I was suggesting in the discussion thread.=20
>> Perhaps I'll go with `indirect` for now, unless anyone can suggest=20
>> something better. I'm probably going to start drawing up a formal propos=
al=20
>> since no one seems to have much feedback.
>>
>>
>> What about letting the current std::reference_wrapper do that?
>> std::reference_wrapper behaves already like a function objet when the=20
>> reference variable is a function object. Adding pointer (reference)=20
>> semantics seems quite appropriated to me (at least until we have operato=
r=20
>> dot).
>>
>
> I'm not completely sure what you're suggesting. std::reference_wrapper<T>=
=20
> has mostly reference-like semantics, except for its pointer-like copy=20
> construction and assignment semantics. indirect<T> and=20
> optional_indirect<T> (I'm calling them that from now on) have mostly=20
> pointer-like semantics, except for their reference-like construction=20
> semantics; they also have a much narrower interface than pointers (e.g. n=
o=20
> pointer arithmetic) which makes them a lot easier to use correctly as=20
> non-owning indirection types.
>
> If you are having a hard time understanding the difference, it's probably=
=20
> best to consider equality comparison:
>
> int i =3D {};
> int j =3D {};
>
> reference_wrapper<int> rw =3D i;
> assert(rw =3D=3D j); // passes
>
> indirect<int> in =3D i;
> assert(in !=3D j); // passes
>
> reference_wrapper tests equal if the underlying *value* is equal, like=20
> references; indirect and optional_indirect test equal if they point to=20
> the same object. This is the distinction between *value* and *identity*.
>
> Oh, I didn't saw you wanted pointer semantics. I didn't notice either tha=
t=20
> the link contents was changed since the first post.
>
> =20
Yeah I just changed the names. The functionality remains unchanged. When I=
=20
realised that "view" classes have value-like comparison semantics, it was a=
=20
deal-breaker as far as using the term "view" is concerned.
> Why don't you reuse observer_ptr then? Do we really need two classes=20
> because the way they are initialized? Why not update the interface if we=
=20
> consider it is useful?=20
>
=20
The interfaces of indirect and optional_indirect are sufficiently different=
=20
from that of observer_ptr that I feel it would be more productive to submit=
=20
a separate proposal rather than fight to fundamentally change the existing=
=20
proposal. The standards committee can then look at and compare both=20
proposals and choose to adopt either, both or neither of them.
I agree that a not owning pointer should be initializable from a reference.
>
I don't necessarily agree.
I have come to realize that is counterproductive to think of a type as=20
being "like a pointer" or "like a value" or "like a reference" during the=
=20
design process; it is better that the semantics of a design be driven by=20
the use case rather than such preconceptions. That said, the class must be=
=20
named, so the question is, what constitutes a "pointer type". One=20
characteristic I would expect of a "pointer type" is that its primary means=
=20
of construction be from a pointer. observer_ptr fits the bill; indirect=20
does not.
Now, if you have looked at my sample implementation, you will notice that=
=20
indirect and optional_indirect *are* explicitly constructible from raw=20
pointers. However, this is not an essential part of the design; for=20
optional_indirect, this is provided for convenience, otherwise conversion=
=20
from pointer looks something like this:
auto i =3D p ? optional_indirect<int>(*p) : nullopt;
Not nice. Much better to support this:
auto i =3D optional_indirect<int>(p);
If the compiler fails to optimize away the conditional check, this may also=
=20
have some performance benefit. For indirect, run-time checked construction=
=20
from a pointer is supported only for symmetry with optional_indirect. It is=
=20
entirely possible that it may be removed at some point in the future.
indirect and optional_indirect are primarily (implicitly) constructible=20
from references. They are (explicitly) constructible from pointers for=20
convenience only. In my view, this makes them sufficiently different from=
=20
raw pointers that it no longer makes sense to call them "pointer types".=20
Indeed, the factory functions make_indirect and make_optional_indirect do=
=20
not have overloads that take pointers.
Are there other differences?
>
The main difference is that observer_ptr<T> has an "empty"/"null" state,=20
while indirect<T> does not. I'd say this is a pretty big difference.=20
optional_indirect<T> is merely a syntactic/memory-usage optimization of=20
optional<indirect<T>>.
Aside from allowing implicit construction from and comparison with T&, the=
=20
differences between optional_indirect<T> and observer_ptr<T> are:
- optional_indirect partially copies the interface of optional (use of=
=20
nullopt; value and value_or)
- observer_ptr partially copies the interface of unique_ptr (use of=20
nullptr; reset and release)
- optional_indirect<T> converts explicitly, not implicitly, to T*=20
(implicit conversion doesn't make sense for a non-pointer type)
- optional_indirect<T> has a get_pointer free function instead of a get=
=20
member function (get doesn't make sense for a non-pointer type)
=20
Should indirect<T> behave like an hypothetical not_null<observer_ptr<T>>?=
=20
> or just not_null<T*>? Note that I'm talking here of an hypothetical=20
> std::not_null class, not the gsl;;not_null.
>
Actually, yes. That is probably a good way to put it to make people=20
understand what my design process has been. Take observer_ptr<T> and=20
not_null<observer_ptr<T>> and then design from scratch what you consider to=
=20
be the ideal interface for such types. I ended up with indirect and=20
optional_indirect.
You might have by now noticed the big difference between these two designs;=
=20
indirect is given an "empty" state by wrapping it in an optional, while=20
observer_ptr has an "empty" state that is suppressed by wrapping it in=20
not_null. There is something that appeals to me aesthetically about adding=
=20
functionality rather than suppressing it. But the impact is more than=20
aesthetic; consider how one would use make functions and auto type=20
deduction with both designs:
auto m_null =3D make_observer(x); // assuming `observer_ptr` supported=20
construction from `T&`
auto n_null =3D make_not_null(a); // presumably `make_not_null` performs a=
=20
run-time check
auto n_null =3D make_indirect(x); // no run-time check
auto m_null =3D make_optional(x); // no run-time check
The run-time performance hit is a result of choosing "maybe null" (i.e.=20
observer_ptr) as the default. If you need another example, the protection=
=20
provided by not_null can be circumvented:
not_null<observer_ptr<int>> n_null =3D i;
observer_ptr<int>& obs =3D n_null;
n_null =3D nullptr; // `n_null` is now null
This is impossible to do with indirect/optional.
>
> Would optional_view<T> behave differently than optional<view<T>>? If yes,=
=20
>> when and why?
>>
>>
>>
> They are mostly functionally equivalent. As far as I can tell,=20
> optional_indirect offers two advantages:
>
> 1. optional<indirect<T>> *probably* occupies twice as much memory as=
=20
> optional_indirect<T>, because the former needs to store a flag=20
> indicating whether it contains a value, while the latter uses the null=
=20
> pointer state to indicate emptiness. If optional_indirect didn't=20
> exist, some people may not use optional<indirect<T>> just to avoid the=
=20
> additional memory cost compared to T*.
> =20
> We could have a specialization that preserves the interface and improves=
=20
> the space performances, isn't it?
> I don't know how the committee fills about specializations like this one.=
=20
>
You cannot preserve the interface *and* improve space performance, because=
=20
optional<T>::operator* and optional<T>::value both return T&; thus,=20
optional<T> must hold onto an instance of T. Providing a specialization of=
=20
the interface for indirect seems like a bad idea to me. I like consistency;=
=20
better to provide a separate type (optional_indirect).
=20
> =20
>
>
> 1. There are situations when you have to dereference (*) an=20
> optional<indirect<T>> but not an optional_indirect<T>, most=20
> significantly when calling indirect::operator* or indirect::operator->=
..=20
> This is a syntactic nuisance. Compare this:
>
> foo f;
> optional<indirect<foo>> o =3D f;
> (*o)->bar =3D 42;
>
> You could use here o->bar also
>
I don't think you can. Chaining of the calls to operator-> would only occur=
=20
if optional<indirect<T>>::operator-> returned indirect<T>& instead of=20
indirect<T>*.=20
=20
>
> o.value()->bar =3D 42;
> foo* p =3D static_cast<foo*>(*o);
>
> with this:
>
>
> foo f;
> optional_indirect<foo> o =3D f;
> o->bar =3D 42;
> o.value().bar =3D 42;
> foo* p =3D static_cast<foo*>(o);
>
>
> I'm not sure yet to want two new class for just these differences, but I=
=20
> can change.
> I believe it is worth seen how a better observer_ptr and an orthogonal=20
> not_null wrapper behave together.
>
You know by now why I consider indirect<T>/optional<indirect<T>> to be=20
preferable to optional_ptr<T>/not_null<optional_ptr<T>>. Sure, it's a shame=
=20
that optional<indirect<T>> is sub-optimal, but other than adding=20
optional_indirect<T>, I don't see any way around it.
=20
>
> Vicente
>
> --=20
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to=20
> 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=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/60f5b2af-99c=
c-7cfa-a123-617de4f2f274%40wanadoo.fr=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/60f5b2af-99=
cc-7cfa-a123-617de4f2f274%40wanadoo.fr?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/1e6fde8a-c3da-4da7-a35d-3d912efadcc8%40isocpp.or=
g.
------=_Part_8680_166659439.1479781475004
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, Nov 22, 2016 at 3:00 AM, Vicente J. Botet Escriba <span dir=3D"ltr"><=
;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bote=
t@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF"><span class=3D"gmail-">
<div class=3D"gmail-m_-1657027200406841220moz-cite-prefix">Le 21/11/201=
6 =C3=A0 02:26,
<a class=3D"gmail-m_-1657027200406841220moz-txt-link-abbreviated" hre=
f=3D"mailto:joseph.thomson@gmail.com" target=3D"_blank">joseph.thomson@gmai=
l.com</a> a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Monday, 21 November 2016 05:30:45 UTC+8, Vicente J. Botet
Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<div>Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit=C2=
=A0:<br>
</div>
<blockquote type=3D"cite">
<p dir=3D"ltr">On 20 Nov 2016 03:09, "Tony V E" <=
;<a rel=3D"nofollow">tvan...@gmail.com</a>>
wrote:<br>
><br>
> Jonathan's class was recently changed to
polymorphic_value. (And/or clone_ptr if it gets split
into 2 classes)</p>
<p dir=3D"ltr">Great. That's exactly what I was suggestin=
g
in the discussion thread. Perhaps I'll go with
`indirect` for now, unless anyone can suggest something
better. I'm probably going to start drawing up a formal
proposal since no one seems to have much feedback.</p>
</blockquote>
<br>
What about letting the current std::reference_wrapper do
that?<br>
std::reference_wrapper behaves already like a function objet
when the reference variable is a function object. Adding
pointer (reference) semantics seems quite appropriated to me
(at least until we have operator dot).<br>
</div>
</blockquote>
<div><br>
I'm not completely sure what you're suggesting. <span sty=
le=3D"font-family: courier new,monospace;">std::reference_wrapper<T><=
/span>
has mostly reference-like semantics, except for its
pointer-like copy construction and assignment semantics. <span st=
yle=3D"font-family: courier new,monospace;">indirect<T></span>
and <span style=3D"font-family: courier new,monospace;">optional_=
indirect<T></span>
(I'm calling them that from now on) have mostly pointer-like
semantics, except for their reference-like construction
semantics; they also have a much narrower interface than
pointers (e.g. no pointer arithmetic) which makes them a lot
easier to use correctly as non-owning indirection types.<br>
<br>
If you are having a hard time understanding the difference,
it's probably best to consider equality comparison:<br>
<br>
<span style=3D"font-family: courier new,monospace;">int i =3D {};=
<br>
int j =3D {};<br>
<br>
reference_wrapper<int> rw =3D i;<br>
assert(rw =3D=3D j); // passes<br>
<br>
indirect<int> in =3D i;<br>
assert(in !=3D j); // passes</span><br>
<br>
<span style=3D"font-family: courier new,monospace;">reference_wra=
pper</span>
tests equal if the underlying <i>value</i> is equal, like
references; <span style=3D"font-family: courier new,monospace;">i=
ndirect</span>
and <span style=3D"font-family: courier new,monospace;">optional_=
indirect</span>
test equal if they point to the same object. This is the
distinction between <i>value</i> and <i>identity</i>.<br>
</div>
</div>
</blockquote></span>
Oh, I didn't saw you wanted pointer semantics. I didn't notice
either that the link contents was changed since the first post.<br>
<br></div></blockquote><div>=C2=A0<br></div><div>Yeah I just changed th=
e=20
names. The functionality remains unchanged. When I realised that "view=
"=20
classes have value-like comparison semantics, it was a deal-breaker as=20
far as using the term "view" is concerned.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bor=
der-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div bgcolor=3D=
"#FFFFFF">
<br>
Why don't you reuse observer_ptr then? Do we really need two classe=
s
because the way they are initialized? Why not update the interface
if we consider it is useful? </div></blockquote><div>=C2=A0</div><div>T=
he
interfaces of <span style=3D"font-family: courier new,monospace;">indirect=
</span> and <span style=3D"font-family: courier new,monospace;">optional_in=
direct</span> are sufficiently different
from that of <span style=3D"font-family: courier new,monospace;">observer_=
ptr</span> that I feel it would be more productive to=20
submit a separate proposal rather than fight to fundamentally change the
existing proposal. The standards committee can then look at and compare
both proposals and choose to adopt either, both or neither of them.<br></d=
iv><div><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I agree that a not owning pointer should be initializable from a
reference.<br></blockquote><div><br></div>I don't necessarily agree=
..<br><br>I
have come to realize that is counterproductive to think of a type
as being "like a pointer" or "like a value" or "l=
ike a reference"=20
during the design process; it=20
is better that the semantics of a design be driven by the use=20
case rather than such preconceptions. That said, the class must be=20
named, so the question=20
is, what constitutes a "pointer type". One characteristic I would=
expect
of a "pointer type" is that its primary means of construction be=
from a
pointer. <span style=3D"font-family: courier new,monospace;">observer_ptr<=
/span> fits the bill; <span style=3D"font-family: courier new,monospace;">i=
ndirect</span> does=20
not.<br><div><br></div><div>Now, if you have looked at my sample implementa=
tion, you will notice that <span style=3D"font-family: courier new,monospac=
e;">indirect</span> and <span style=3D"font-family: courier new,monospace;"=
>optional_indirect</span> <i>are</i>
explicitly constructible from raw pointers. However, this is not an=20
essential part of the design; for <span style=3D"font-family: courier new,m=
onospace;">optional_indirect</span>, this is provided=20
for convenience, otherwise conversion from pointer looks something like=20
this:<br><br></div><div><div style=3D"background-color: rgb(250, 250, 250);=
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">?</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> optional_indirect</=
span><span style=3D"color: #080;" class=3D"styled-by-prettify"><int><=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(*</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">p</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-prettify">:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> nullopt</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span></div></code></div><br></div><div>Not nice. Much =
better to support this:<br><br></div><div><div style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> optional_indirect</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify"><int></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">p</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span></div></code></div><br></div>If
the compiler fails to optimize away the conditional check, this may=20
also have some performance benefit. For <span style=3D"font-family: courier=
new,monospace;">indirect</span>, run-time checked=20
construction from a pointer is supported only for symmetry with <span style=
=3D"font-family: courier new,monospace;">
optional_indirect</span>. It is entirely possible that it may be removed at=
some point=20
in the future.<br><br></div><div><span style=3D"font-family: courier new,mo=
nospace;">indirect</span> and <span style=3D"font-family: courier new,monos=
pace;">optional_indirect</span> are=20
primarily (implicitly) constructible from references. They are=20
(explicitly) constructible from pointers for convenience only. In my=20
view, this makes them sufficiently different from raw pointers that it=20
no longer makes sense to call them "pointer types". Indeed, the f=
actory=20
functions <span style=3D"font-family: monospace,monospace;">make_indirect</=
span> and <span style=3D"font-family: monospace,monospace;">make_optional_i=
ndirect</span> do not have overloads that take pointers.<br></div><div><br>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Are there other =
differences?<br></blockquote><br></div><div>The
main difference is that <span style=3D"font-family: courier new,monospace;=
">observer_ptr<T></span> has an "empty"/"null"=20
state, while <span style=3D"font-family: courier new,monospace;">indirect&l=
t;T></span> does not. I'd say this is a pretty big=20
difference. <span style=3D"font-family: courier new,monospace;">optional_in=
direct<T></span> is merely a=20
syntactic/memory-usage optimization of=20
<span style=3D"font-family: courier new,monospace;">optional<indirect<=
;T>></span>.<br><br>Aside from allowing implicit construction from an=
d comparison with <span style=3D"font-family: courier new,monospace;">T&=
;</span>, the differences between <span style=3D"font-family: courier new,m=
onospace;">optional_indirect<T></span> and <span style=3D"font-family=
: courier new,monospace;">observer_ptr<T></span> are:<br><ul><li><spa=
n style=3D"font-family: courier new,monospace;">optional_indirect</span> pa=
rtially copies the interface of <span style=3D"font-family: courier new,mon=
ospace;">optional</span> (use of <span style=3D"font-family: courier new,mo=
nospace;">nullopt</span>; <span style=3D"font-family: courier new,monospace=
;">value</span> and <span style=3D"font-family: courier new,monospace;">val=
ue_or</span>)</li><li><span style=3D"font-family: courier new,monospace;">o=
bserver_ptr</span> partially copies the interface of <span style=3D"font-fa=
mily: courier new,monospace;">unique_ptr</span> (use of <span style=3D"font=
-family: courier new,monospace;">nullptr</span>; <span style=3D"font-family=
: courier new,monospace;">reset</span> and <span style=3D"font-family: cour=
ier new,monospace;">release</span>)</li><li><span style=3D"font-family: cou=
rier new,monospace;">optional_indirect<T></span> converts explicitly,=
not implicitly, to <span style=3D"font-family: courier new,monospace;">T*<=
/span> (implicit conversion doesn't make sense for a non-pointer type)<=
/li><li><span style=3D"font-family: courier new,monospace;">optional_indire=
ct<T></span> has a <span style=3D"font-family: courier new,monospace;=
">get_pointer</span> free function instead of a <span style=3D"font-family:=
courier new,monospace;">get</span> member function (<span style=3D"font-fa=
mily: courier new,monospace;">get</span> doesn't make sense for a non-p=
ointer type)<br></li></ul></div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 2=
04, 204); padding-left: 1ex;"><div bgcolor=3D"#FFFFFF">
Should indirect<T> behave like an hypothetical
not_null<observer_ptr<T>>? or just not_null<T*>?
Note that I'm talking here of an hypothetical std::not_null class,
not the gsl;;not_null.<br></div></blockquote><div><br></div><div>Actual=
ly,
yes. That is probably a good way to put it to make people understand=20
what my design process has been. Take <span style=3D"font-family: courier n=
ew,monospace;">observer_ptr<T></span> and=20
<span style=3D"font-family: courier new,monospace;">not_null<observer_pt=
r<T>></span> and then design from scratch what you consider to be =
the=20
ideal interface for such types. I ended up with <span style=3D"font-family:=
courier new,monospace;">indirect</span> and=20
<span style=3D"font-family: courier new,monospace;">optional_indirect</span=
>.<br><br></div><div>You might have by now noticed the=20
big difference between these two designs; <span style=3D"font-family: couri=
er new,monospace;">indirect</span> is given an "empty"=20
state by wrapping it in an <span style=3D"font-family: courier new,monospac=
e;">optional</span>, while <span style=3D"font-family: courier new,monospac=
e;">observer_ptr</span> has an "empty"=20
state that is suppressed by wrapping it in <span style=3D"font-family: cour=
ier new,monospace;">not_null</span>. There is something=20
that appeals to me aesthetically about adding functionality rather than=20
suppressing it. But the impact is more than aesthetic; consider how one wou=
ld use <span style=3D"font-family: courier new,monospace;">make</span> func=
tions and <span style=3D"font-family: courier new,monospace;">auto</span> t=
ype deduction with both designs:<br><br></div><div style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> m_null </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> make_observer</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">x</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: #800;" class=3D"styled-by-prettify">// assu=
ming `observer_ptr` supported construction from `T&`</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> n_null </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> make_not_null</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// pr=
esumably `make_not_null` performs a run-time check</span></div></code></div=
><br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: brea=
k-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> n_null <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> make_indirect</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">x</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: #800;" cla=
ss=3D"styled-by-prettify">// no run-time check</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"> m_null </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> make_optional</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">// no run-time=
check</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><div><br>The run-time performance hit is a result=
of choosing "maybe null" (i.e. <span style=3D"font-family: couri=
er new,monospace;">observer_ptr</span>) as the default. If you need another=
example, the protection provided by <span style=3D"font-family: courier ne=
w,monospace;">not_null</span> can be circumvented:<br><br><div style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pret=
typrint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">not_null</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">observer_ptr</span><span style=3D=
"color: #080;" class=3D"styled-by-prettify"><int></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> n_null </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>observer_ptr</span><span style=3D"color: #080;" class=3D=
"styled-by-prettify"><int></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> obs </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> n_null</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>n=
_null </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">nullptr</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: #8=
00;" class=3D"styled-by-prettify">// `n_null` is now null</span></div></cod=
e></div><br>This is impossible to do with <span style=3D"font-family: couri=
er new,monospace;">indirect</span>/<span style=3D"font-family: courier new,=
monospace;">optional</span>.<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
padding-left: 1ex;"><div bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr"><span class=3D"gmail-">
<div><br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8e=
x; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div> Would optional_view<T> behave differently than
optional<view<T>>? If yes, when and why?<br>
<br>
<br>
</div>
</blockquote>
</span><div><br><span class=3D"gmail-">
They are mostly functionally equivalent. As far as I can tell,
<span style=3D"font-family: courier new,monospace;">optional_indi=
rect</span>
offers two advantages:<br>
<ol><li><span style=3D"font-family: courier new,monospace;">optio=
nal<indirect<T>></span>
<i>probably</i> occupies twice as much memory as <span style=
=3D"font-family: courier new,monospace;">optional_indirect<T></span>,
because the former needs to store a flag indicating
whether it contains a value, while the latter uses the
null pointer state to indicate emptiness. If <span style=3D"f=
ont-family: courier new,monospace;">optional_indirect</span>
didn't exist, some people may not use <span style=3D"font=
-family: courier new,monospace;">optional<indirect<T>></span>
just to avoid the additional memory cost compared to <span st=
yle=3D"font-family: courier new,monospace;">T*</span>.<br>
</li></ol>
</span></div>
</div>
</blockquote>
We could have a specialization that preserves the interface and
improves the space performances, isn't it?<br>
I don't know how the committee fills about specializations like thi=
s
one. <br></div></blockquote><div><br></div><div>You cannot preserve the=
interface <i>and</i> improve space performance, because <span style=3D"fon=
t-family: monospace,monospace;">optional<T>::operator*</span> and <sp=
an style=3D"font-family: monospace,monospace;">optional<T>::value</sp=
an> both return <span style=3D"font-family: monospace,monospace;">T&</s=
pan>; thus, <span style=3D"font-family: monospace,monospace;">optional<T=
></span> must hold onto an instance of <span style=3D"font-family: monos=
pace,monospace;">T</span>.
Providing a specialization of the interface for <span style=3D"font-family=
: courier new,monospace;">indirect</span> seems like a=20
bad idea to me. I like consistency; better to provide a separate type (<spa=
n style=3D"font-family: monospace,monospace;">optional_indirect</span>).<br=
></div><div>=C2=A0</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;"><div bgcolor=3D"#FFFFFF"><span class=3D"gmail-">
=C2=A0<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<ol><li>There are situations when you have to dereference (<span =
style=3D"font-family: courier new,monospace;">*</span>) an
<span style=3D"font-family: courier new,monospace;">optional&=
lt;indirect<T>></span>
but not an <span style=3D"font-family: courier new,monospace;=
">optional_indirect<T></span>, most
significantly when calling <span style=3D"font-family: courie=
r new,monospace;">indirect::operator*</span> or <span style=3D"font-family:=
courier new,monospace;">indirect::operator-></span>.
This is a syntactic nuisance. Compare this:</li></ol>
<div style=3D"margin-left: 40px;">
<div style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px;" class=3D"gm=
ail-m_-1657027200406841220prettyprint"><code class=3D"gmail-m_-165702720040=
6841220prettyprint">
<div class=3D"gmail-m_-1657027200406841220subprettyprint"><=
span style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220st=
yled-by-prettify">foo f</span><span style=3D"color: rgb(102, 102, 0);" clas=
s=3D"gmail-m_-1657027200406841220styled-by-prettify">;</span><span style=3D=
"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prett=
ify"><br>
optional</span><span style=3D"color: rgb(102, 102, 0);"=
class=3D"gmail-m_-1657027200406841220styled-by-prettify"><</span><span =
style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-=
by-prettify">indirect</span><span style=3D"color: rgb(0, 136, 0);" class=3D=
"gmail-m_-1657027200406841220styled-by-prettify"><foo></span><span st=
yle=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-1657027200406841220style=
d-by-prettify">></span><span style=3D"color: rgb(0, 0, 0);" class=3D"gma=
il-m_-1657027200406841220styled-by-prettify"> o </span><span style=3D"color=
: rgb(102, 102, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettif=
y">=3D</span><span style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027=
200406841220styled-by-prettify"> f</span><span style=3D"color: rgb(102, 102=
, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify">;</span><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styl=
ed-by-prettify"><br>
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
gmail-m_-1657027200406841220styled-by-prettify">(*</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"=
>o</span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-1657027=
200406841220styled-by-prettify">)-></span><span style=3D"color: rgb(0, 0=
, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify">bar
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
gmail-m_-1657027200406841220styled-by-prettify">=3D</span><span style=3D"co=
lor: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify=
"> </span><span style=3D"color: rgb(0, 102, 102);" class=3D"gmail-m_-165702=
7200406841220styled-by-prettify">42</span><span style=3D"color: rgb(102, 10=
2, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify">;</span><s=
pan style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220sty=
led-by-prettify"><br>
</span></div>
</code></div>
</div>
</div>
</div>
</blockquote>
</span><code>You could use here </code>o->bar also</div></blockquote=
><div><br></div><div>I don't think you can. Chaining of the calls to <s=
pan style=3D"font-family: monospace,monospace;">operator-></span> would =
only occur if <span style=3D"font-family: monospace,monospace;">optional<=
;indirect<T>>::operator-></span> returned <span style=3D"font-f=
amily: monospace,monospace;">indirect<T>&</span> instead of <span=
style=3D"font-family: monospace,monospace;">indirect<T>*</span>. <br=
></div><div>=C2=A0</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;"><div bgcolor=3D"#FFFFFF"><span class=3D"gmail-"><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div style=3D"margin-left: 40px;">
<div style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px;" class=3D"gm=
ail-m_-1657027200406841220prettyprint"><code class=3D"gmail-m_-165702720040=
6841220prettyprint">
<div class=3D"gmail-m_-1657027200406841220subprettyprint"><=
span style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220st=
yled-by-prettify">o</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"gmail-m_-1657027200406841220styled-by-prettify">.</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"=
>value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-165=
7027200406841220styled-by-prettify">()-></span><span style=3D"color: rgb=
(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify">bar
</span><span style=3D"color: rgb(102, 102, 0);" class=3D"=
gmail-m_-1657027200406841220styled-by-prettify">=3D</span><span style=3D"co=
lor: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify=
"> </span><span style=3D"color: rgb(0, 102, 102);" class=3D"gmail-m_-165702=
7200406841220styled-by-prettify">42</span><span style=3D"color: rgb(102, 10=
2, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify">;</span><s=
pan style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220sty=
led-by-prettify"><br>
foo</span><span style=3D"color: rgb(102, 102, 0);" clas=
s=3D"gmail-m_-1657027200406841220styled-by-prettify">*</span><span style=3D=
"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prett=
ify"> p </span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-1=
657027200406841220styled-by-prettify">=3D</span><span style=3D"color: rgb(0=
, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"> </span>=
<span style=3D"color: rgb(0, 0, 136);" class=3D"gmail-m_-165702720040684122=
0styled-by-prettify">static_cast</span><span style=3D"color: rgb(102, 102, =
0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"><</span><s=
pan style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220sty=
led-by-prettify">foo</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"gmail-m_-1657027200406841220styled-by-prettify">*>(*</span><span sty=
le=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-=
prettify">o</span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m=
_-1657027200406841220styled-by-prettify">);</span></div>
</code></div>
</div>
<br>
<p style=3D"margin-left: 40px;">with this:</p>
<p style=3D"margin-left: 40px;"><br>
</p>
<div style=3D"background-color: rgb(250, 250, 250); border-color:=
rgb(187, 187, 187); border-style: solid; border-width: 1px;" class=3D"gmai=
l-m_-1657027200406841220prettyprint"><code class=3D"gmail-m_-16570272004068=
41220prettyprint">
<div class=3D"gmail-m_-1657027200406841220subprettyprint"><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styl=
ed-by-prettify">foo f</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"gmail-m_-1657027200406841220styled-by-prettify">;</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-pretti=
fy"><br>
optional_indirect</span><span style=3D"color: rgb(0, 136,=
0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"><foo><=
/span><span style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-16570272004068=
41220styled-by-prettify"> o </span><span style=3D"color: rgb(102, 102, 0);"=
class=3D"gmail-m_-1657027200406841220styled-by-prettify">=3D</span><span s=
tyle=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-b=
y-prettify"> f</span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmai=
l-m_-1657027200406841220styled-by-prettify">;</span><span style=3D"color: r=
gb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"><br>
o</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"gmail-m_-1657027200406841220styled-by-prettify">-></span><span style=3D=
"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prett=
ify">bar </span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-=
1657027200406841220styled-by-prettify">=3D</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"> </span=
><span style=3D"color: rgb(0, 102, 102);" class=3D"gmail-m_-165702720040684=
1220styled-by-prettify">42</span><span style=3D"color: rgb(102, 102, 0);" c=
lass=3D"gmail-m_-1657027200406841220styled-by-prettify">;</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-pr=
ettify"><br>
o</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"gmail-m_-1657027200406841220styled-by-prettify">.</span><span style=3D"col=
or: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"=
>value</span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-165=
7027200406841220styled-by-prettify">().</span><span style=3D"color: rgb(0, =
0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify">bar </span=
><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-165702720040684=
1220styled-by-prettify">=3D</span><span style=3D"color: rgb(0, 0, 0);" clas=
s=3D"gmail-m_-1657027200406841220styled-by-prettify"> </span><span style=3D=
"color: rgb(0, 102, 102);" class=3D"gmail-m_-1657027200406841220styled-by-p=
rettify">42</span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m=
_-1657027200406841220styled-by-prettify">;</span><span style=3D"color: rgb(=
0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"><br>
foo</span><span style=3D"color: rgb(102, 102, 0);" class=
=3D"gmail-m_-1657027200406841220styled-by-prettify">*</span><span style=3D"=
color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-pretti=
fy"> p </span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-16=
57027200406841220styled-by-prettify">=3D</span><span style=3D"color: rgb(0,=
0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"> </span><=
span style=3D"color: rgb(0, 0, 136);" class=3D"gmail-m_-1657027200406841220=
styled-by-prettify">static_cast</span><span style=3D"color: rgb(102, 102, 0=
);" class=3D"gmail-m_-1657027200406841220styled-by-prettify"><</span><sp=
an style=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styl=
ed-by-prettify">foo</span><span style=3D"color: rgb(102, 102, 0);" class=3D=
"gmail-m_-1657027200406841220styled-by-prettify">*>(</span><span style=
=3D"color: rgb(0, 0, 0);" class=3D"gmail-m_-1657027200406841220styled-by-pr=
ettify">o</span><span style=3D"color: rgb(102, 102, 0);" class=3D"gmail-m_-=
1657027200406841220styled-by-prettify">);</span></div>
</code></div>
<p style=3D"margin-left: 40px;"><br>
</p>
</div>
</div>
</blockquote></span>
I'm not sure yet to want two new class for just these differences,
but I can change.<br>
I believe it is worth seen how a better observer_ptr and an
orthogonal not_null wrapper behave together.<br></div></blockquote><div=
><br></div><div>You know by now why I consider <span style=3D"font-family: =
monospace,monospace;">indirect<T></span>/<span style=3D"font-family: =
monospace,monospace;">optional<indirect<T>></span> to be prefer=
able to <span style=3D"font-family: monospace,monospace;">optional_ptr<T=
></span>/<span style=3D"font-family: monospace,monospace;">not_null<o=
ptional_ptr<T>></span>. Sure, it's a shame that <span style=3D=
"font-family: monospace,monospace;">optional<indirect<T>></span=
> is sub-optimal, but other than adding <span style=3D"font-family: monospa=
ce,monospace;">optional_indirect<T></span>, I don't see any way a=
round it.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;"><div bgcolor=3D"#FFFFFF">
<br>
Vicente<br>
<br>
</div><span class=3D"gmail-">
-- <br>
You received this message because you are subscribed to a topic in the=20
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/a=
K1IyB29tF0/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+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/60f5b2af-99cc-7cfa-a123-617de4f2f274%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/60f5=
b2af-99cc-7cfa-<wbr>a123-617de4f2f274%40wanadoo.fr</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" 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/1e6fde8a-c3da-4da7-a35d-3d912efadcc8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e6fde8a-c3da-4da7-a35d-3d912efadcc8=
%40isocpp.org</a>.<br />
------=_Part_8680_166659439.1479781475004--
------=_Part_8679_230267797.1479781475003--
.
Author: joseph.thomson@gmail.com
Date: Mon, 21 Nov 2016 18:35:47 -0800 (PST)
Raw View
------=_Part_2850_66208461.1479782147758
Content-Type: multipart/alternative;
boundary="----=_Part_2851_747205465.1479782147760"
------=_Part_2851_747205465.1479782147760
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tuesday, 22 November 2016 10:24:35 UTC+8, joseph....@gmail.com wrote:
>
> On Tue, Nov 22, 2016 at 3:00 AM, Vicente J. Botet Escriba <
> vicente.botet@wanadoo.fr> wrote:
>
>> Le 21/11/2016 =C3=A0 02:26, joseph.thomson@gmail.com a =C3=A9crit :
>>
>>
>>
>> On Monday, 21 November 2016 05:30:45 UTC+8, Vicente J. Botet Escriba=20
>> wrote:=20
>>>
>>> Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit :
>>>
>>> On 20 Nov 2016 03:09, "Tony V E" <tvan...@gmail.com> wrote:
>>> >
>>> > Jonathan's class was recently changed to polymorphic_value. (And/or=
=20
>>> clone_ptr if it gets split into 2 classes)
>>>
>>> Great. That's exactly what I was suggesting in the discussion thread.=
=20
>>> Perhaps I'll go with `indirect` for now, unless anyone can suggest=20
>>> something better. I'm probably going to start drawing up a formal propo=
sal=20
>>> since no one seems to have much feedback.
>>>
>>>
>>> What about letting the current std::reference_wrapper do that?
>>> std::reference_wrapper behaves already like a function objet when the=
=20
>>> reference variable is a function object. Adding pointer (reference)=20
>>> semantics seems quite appropriated to me (at least until we have operat=
or=20
>>> dot).
>>>
>>
>> I'm not completely sure what you're suggesting. std::reference_wrapper<T=
>=20
>> has mostly reference-like semantics, except for its pointer-like copy=20
>> construction and assignment semantics. indirect<T> and=20
>> optional_indirect<T> (I'm calling them that from now on) have mostly=20
>> pointer-like semantics, except for their reference-like construction=20
>> semantics; they also have a much narrower interface than pointers (e.g. =
no=20
>> pointer arithmetic) which makes them a lot easier to use correctly as=20
>> non-owning indirection types.
>>
>> If you are having a hard time understanding the difference, it's probabl=
y=20
>> best to consider equality comparison:
>>
>> int i =3D {};
>> int j =3D {};
>>
>> reference_wrapper<int> rw =3D i;
>> assert(rw =3D=3D j); // passes
>>
>> indirect<int> in =3D i;
>> assert(in !=3D j); // passes
>>
>> reference_wrapper tests equal if the underlying *value* is equal, like=
=20
>> references; indirect and optional_indirect test equal if they point to=
=20
>> the same object. This is the distinction between *value* and *identity*.
>>
>> Oh, I didn't saw you wanted pointer semantics. I didn't notice either=20
>> that the link contents was changed since the first post.
>>
>> =20
> Yeah I just changed the names. The functionality remains unchanged. When =
I=20
> realised that "view" classes have value-like comparison semantics, it was=
a=20
> deal-breaker as far as using the term "view" is concerned.
>
>
>> Why don't you reuse observer_ptr then? Do we really need two classes=20
>> because the way they are initialized? Why not update the interface if we=
=20
>> consider it is useful?=20
>>
> =20
> The interfaces of indirect and optional_indirect are sufficiently=20
> different from that of observer_ptr that I feel it would be more=20
> productive to submit a separate proposal rather than fight to fundamental=
ly=20
> change the existing proposal. The standards committee can then look at an=
d=20
> compare both proposals and choose to adopt either, both or neither of the=
m.
>
> I agree that a not owning pointer should be initializable from a referenc=
e.
>>
>
> I don't necessarily agree.
>
> I have come to realize that is counterproductive to think of a type as=20
> being "like a pointer" or "like a value" or "like a reference" during the=
=20
> design process; it is better that the semantics of a design be driven by=
=20
> the use case rather than such preconceptions. That said, the class must b=
e=20
> named, so the question is, what constitutes a "pointer type". One=20
> characteristic I would expect of a "pointer type" is that its primary mea=
ns=20
> of construction be from a pointer. observer_ptr fits the bill; indirect=
=20
> does not.
>
> Now, if you have looked at my sample implementation, you will notice that=
=20
> indirect and optional_indirect *are* explicitly constructible from raw=20
> pointers. However, this is not an essential part of the design; for=20
> optional_indirect, this is provided for convenience, otherwise conversion=
=20
> from pointer looks something like this:
>
> auto i =3D p ? optional_indirect<int>(*p) : nullopt;
>
> Not nice. Much better to support this:
>
> auto i =3D optional_indirect<int>(p);
>
> If the compiler fails to optimize away the conditional check, this may=20
> also have some performance benefit. For indirect, run-time checked=20
> construction from a pointer is supported only for symmetry with=20
> optional_indirect. It is entirely possible that it may be removed at some=
=20
> point in the future.
>
> indirect and optional_indirect are primarily (implicitly) constructible=
=20
> from references. They are (explicitly) constructible from pointers for=20
> convenience only. In my view, this makes them sufficiently different from=
=20
> raw pointers that it no longer makes sense to call them "pointer types".=
=20
> Indeed, the factory functions make_indirect and make_optional_indirect do=
=20
> not have overloads that take pointers.
>
> Are there other differences?
>>
>
> The main difference is that observer_ptr<T> has an "empty"/"null" state,=
=20
> while indirect<T> does not. I'd say this is a pretty big difference.=20
> optional_indirect<T> is merely a syntactic/memory-usage optimization of=
=20
> optional<indirect<T>>.
>
> Aside from allowing implicit construction from and comparison with T&,=20
> the differences between optional_indirect<T> and observer_ptr<T> are:
>
> - optional_indirect partially copies the interface of optional (use of=
=20
> nullopt; value and value_or)
> - observer_ptr partially copies the interface of unique_ptr (use of=20
> nullptr; reset and release)
> - optional_indirect<T> converts explicitly, not implicitly, to T*=20
> (implicit conversion doesn't make sense for a non-pointer type)
> - optional_indirect<T> has a get_pointer free function instead of a ge=
t=20
> member function (get doesn't make sense for a non-pointer type)
> =20
>
> Should indirect<T> behave like an hypothetical not_null<observer_ptr<T>>?=
=20
>> or just not_null<T*>? Note that I'm talking here of an hypothetical=20
>> std::not_null class, not the gsl;;not_null.
>>
>
> Actually, yes. That is probably a good way to put it to make people=20
> understand what my design process has been. Take observer_ptr<T> and=20
> not_null<observer_ptr<T>> and then design from scratch what you consider=
=20
> to be the ideal interface for such types. I ended up with indirect and=20
> optional_indirect.
>
> You might have by now noticed the big difference between these two=20
> designs; indirect is given an "empty" state by wrapping it in an optional=
,=20
> while observer_ptr has an "empty" state that is suppressed by wrapping it=
=20
> in not_null. There is something that appeals to me aesthetically about=20
> adding functionality rather than suppressing it. But the impact is more=
=20
> than aesthetic; consider how one would use make functions and auto type=
=20
> deduction with both designs:
>
> auto m_null =3D make_observer(x); // assuming `observer_ptr` supported=20
> construction from `T&`
> auto n_null =3D make_not_null(a); // presumably `make_not_null` performs =
a=20
> run-time check
>
> auto n_null =3D make_indirect(x); // no run-time check
> auto m_null =3D make_optional(x); // no run-time check
>
> The run-time performance hit is a result of choosing "maybe null" (i.e.=
=20
> observer_ptr) as the default. If you need another example, the protection=
=20
> provided by not_null can be circumvented:
>
> not_null<observer_ptr<int>> n_null =3D i;
> observer_ptr<int>& obs =3D n_null;
> n_null =3D nullptr; // `n_null` is now null
>
>
A slight correction (to avoid confusion):
not_null<observer_ptr<int>> n_null =3D i;
observer_ptr<int>& m_null =3D n_null;
m_null =3D nullptr; // `n_null` is now null
One addition point: it seems that gsl::not_null converts only to T, not T&.=
=20
Presumably this means it doesn't support move-only types. Perhaps not_null=
=20
could be designed to avoid the above problem *and* support move-only types.=
=20
I'm not sure. At any rate, I think my point is clear.
This is impossible to do with indirect/optional.
>
>>
>> Would optional_view<T> behave differently than optional<view<T>>? If yes=
,=20
>>> when and why?
>>>
>>>
>>>
>> They are mostly functionally equivalent. As far as I can tell,=20
>> optional_indirect offers two advantages:
>>
>> 1. optional<indirect<T>> *probably* occupies twice as much memory as=
=20
>> optional_indirect<T>, because the former needs to store a flag=20
>> indicating whether it contains a value, while the latter uses the nul=
l=20
>> pointer state to indicate emptiness. If optional_indirect didn't=20
>> exist, some people may not use optional<indirect<T>> just to avoid=20
>> the additional memory cost compared to T*.
>> =20
>> We could have a specialization that preserves the interface and improves=
=20
>> the space performances, isn't it?
>> I don't know how the committee fills about specializations like this one=
..=20
>>
>
> You cannot preserve the interface *and* improve space performance,=20
> because optional<T>::operator* and optional<T>::value both return T&;=20
> thus, optional<T> must hold onto an instance of T. Providing a=20
> specialization of the interface for indirect seems like a bad idea to me.=
=20
> I like consistency; better to provide a separate type (optional_indirect)=
..
> =20
>
>> =20
>>
>>
>> 1. There are situations when you have to dereference (*) an=20
>> optional<indirect<T>> but not an optional_indirect<T>, most=20
>> significantly when calling indirect::operator* or indirect::operator-=
>.=20
>> This is a syntactic nuisance. Compare this:
>>
>> foo f;
>> optional<indirect<foo>> o =3D f;
>> (*o)->bar =3D 42;
>>
>> You could use here o->bar also
>>
>
> I don't think you can. Chaining of the calls to operator-> would only=20
> occur if optional<indirect<T>>::operator-> returned indirect<T>& instead=
=20
> of indirect<T>*.=20
> =20
>
>>
>> o.value()->bar =3D 42;
>> foo* p =3D static_cast<foo*>(*o);
>>
>> with this:
>>
>>
>> foo f;
>> optional_indirect<foo> o =3D f;
>> o->bar =3D 42;
>> o.value().bar =3D 42;
>> foo* p =3D static_cast<foo*>(o);
>>
>>
>> I'm not sure yet to want two new class for just these differences, but I=
=20
>> can change.
>> I believe it is worth seen how a better observer_ptr and an orthogonal=
=20
>> not_null wrapper behave together.
>>
>
> You know by now why I consider indirect<T>/optional<indirect<T>> to be=20
> preferable to optional_ptr<T>/not_null<optional_ptr<T>>. Sure, it's a=20
> shame that optional<indirect<T>> is sub-optimal, but other than adding=20
> optional_indirect<T>, I don't see any way around it.
> =20
>
>>
>> Vicente
>>
>> --=20
>> You received this message because you are subscribed to a topic in the=
=20
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit=20
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to=20
>> 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=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/60f5b2af-99=
cc-7cfa-a123-617de4f2f274%40wanadoo.fr=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/60f5b2af-9=
9cc-7cfa-a123-617de4f2f274%40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
>
--=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/f1c9384b-8ddf-42c6-b7a5-0028a382398a%40isocpp.or=
g.
------=_Part_2851_747205465.1479782147760
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, 22 November 2016 10:24:35 UTC+8, joseph....@gm=
ail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On Tue, Nov 22, 2016 at 3:00 AM, Vicente =
J. Botet Escriba <span dir=3D"ltr"><<a href=3D"mailto:vicente.botet@wana=
doo.fr" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
mailto:vicente.botet@wanadoo.fr';return true;" onclick=3D"this.href=3D&=
#39;mailto:vicente.botet@wanadoo.fr';return true;">vicente.botet@wanado=
o.fr</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF"><span>
<div>Le 21/11/2016 =C3=A0 02:26,
<a href=3D"mailto:joseph.thomson@gmail.com" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D'mailto:joseph.thomson@gmail.com&#=
39;;return true;" onclick=3D"this.href=3D'mailto:joseph.thomson@gmail.c=
om';return true;">joseph.thomson@gmail.com</a> a =C3=A9crit=C2=A0:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Monday, 21 November 2016 05:30:45 UTC+8, Vicente J. Botet
Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Le 20/11/2016 =C3=A0 02:55, Joseph Thomson a =C3=A9crit=C2=
=A0:<br>
</div>
<blockquote type=3D"cite">
<p dir=3D"ltr">On 20 Nov 2016 03:09, "Tony V E" <=
;<a rel=3D"nofollow">tvan...@gmail.com</a>>
wrote:<br>
><br>
> Jonathan's class was recently changed to
polymorphic_value. (And/or clone_ptr if it gets split
into 2 classes)</p>
<p dir=3D"ltr">Great. That's exactly what I was suggestin=
g
in the discussion thread. Perhaps I'll go with
`indirect` for now, unless anyone can suggest something
better. I'm probably going to start drawing up a formal
proposal since no one seems to have much feedback.</p>
</blockquote>
<br>
What about letting the current std::reference_wrapper do
that?<br>
std::reference_wrapper behaves already like a function objet
when the reference variable is a function object. Adding
pointer (reference) semantics seems quite appropriated to me
(at least until we have operator dot).<br>
</div>
</blockquote>
<div><br>
I'm not completely sure what you're suggesting. <span sty=
le=3D"font-family:courier new,monospace">std::reference_wrapper<T></s=
pan>
has mostly reference-like semantics, except for its
pointer-like copy construction and assignment semantics. <span st=
yle=3D"font-family:courier new,monospace">indirect<T></span>
and <span style=3D"font-family:courier new,monospace">optional_in=
direct<T></span>
(I'm calling them that from now on) have mostly pointer-like
semantics, except for their reference-like construction
semantics; they also have a much narrower interface than
pointers (e.g. no pointer arithmetic) which makes them a lot
easier to use correctly as non-owning indirection types.<br>
<br>
If you are having a hard time understanding the difference,
it's probably best to consider equality comparison:<br>
<br>
<span style=3D"font-family:courier new,monospace">int i =3D {};<b=
r>
int j =3D {};<br>
<br>
reference_wrapper<int> rw =3D i;<br>
assert(rw =3D=3D j); // passes<br>
<br>
indirect<int> in =3D i;<br>
assert(in !=3D j); // passes</span><br>
<br>
<span style=3D"font-family:courier new,monospace">reference_wrapp=
er</span>
tests equal if the underlying <i>value</i> is equal, like
references; <span style=3D"font-family:courier new,monospace">ind=
irect</span>
and <span style=3D"font-family:courier new,monospace">optional_in=
direct</span>
test equal if they point to the same object. This is the
distinction between <i>value</i> and <i>identity</i>.<br>
</div>
</div>
</blockquote></span>
Oh, I didn't saw you wanted pointer semantics. I didn't notice
either that the link contents was changed since the first post.<br>
<br></div></blockquote><div>=C2=A0<br></div><div>Yeah I just changed th=
e=20
names. The functionality remains unchanged. When I realised that "view=
"=20
classes have value-like comparison semantics, it was a deal-breaker as=20
far as using the term "view" is concerned.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor=3D"#FFFFFF=
">
<br>
Why don't you reuse observer_ptr then? Do we really need two classe=
s
because the way they are initialized? Why not update the interface
if we consider it is useful? </div></blockquote><div>=C2=A0</div><div>T=
he
interfaces of <span style=3D"font-family:courier new,monospace">indirect</=
span> and <span style=3D"font-family:courier new,monospace">optional_indire=
ct</span> are sufficiently different
from that of <span style=3D"font-family:courier new,monospace">observer_pt=
r</span> that I feel it would be more productive to=20
submit a separate proposal rather than fight to fundamentally change the
existing proposal. The standards committee can then look at and compare
both proposals and choose to adopt either, both or neither of them.<br></d=
iv><div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I agree that a not owning pointer should be initializable from a
reference.<br></blockquote><div><br></div>I don't necessarily agree=
..<br><br>I
have come to realize that is counterproductive to think of a type
as being "like a pointer" or "like a value" or "l=
ike a reference"=20
during the design process; it=20
is better that the semantics of a design be driven by the use=20
case rather than such preconceptions. That said, the class must be=20
named, so the question=20
is, what constitutes a "pointer type". One characteristic I would=
expect
of a "pointer type" is that its primary means of construction be=
from a
pointer. <span style=3D"font-family:courier new,monospace">observer_ptr</s=
pan> fits the bill; <span style=3D"font-family:courier new,monospace">indir=
ect</span> does=20
not.<br><div><br></div><div>Now, if you have looked at my sample implementa=
tion, you will notice that <span style=3D"font-family:courier new,monospace=
">indirect</span> and <span style=3D"font-family:courier new,monospace">opt=
ional_indirect</span> <i>are</i>
explicitly constructible from raw pointers. However, this is not an=20
essential part of the design; for <span style=3D"font-family:courier new,mo=
nospace">optional_indirect</span>, this is provided=20
for convenience, otherwise conversion from pointer looks something like=20
this:<br><br></div><div><div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>=
<span style=3D"color:#008">auto</span><span style=3D"color:#000"> i </span>=
<span style=3D"color:#660">=3D</span><span style=3D"color:#000"> p </span><=
span style=3D"color:#660">?</span><span style=3D"color:#000"> optional_indi=
rect</span><span style=3D"color:#080"><int></span><span style=3D"colo=
r:#660">(*</span><span style=3D"color:#000">p</span><span style=3D"color:#6=
60">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">:=
</span><span style=3D"color:#000"> nullopt</span><span style=3D"color:#660"=
>;</span></div></code></div><br></div><div>Not nice. Much better to support=
this:<br><br></div><div><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div=
><span style=3D"color:#008">auto</span><span style=3D"color:#000"> i </span=
><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> optional_=
indirect</span><span style=3D"color:#080"><int></span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">p</span><span style=3D"color=
:#660">);</span></div></code></div><br></div>If
the compiler fails to optimize away the conditional check, this may=20
also have some performance benefit. For <span style=3D"font-family:courier =
new,monospace">indirect</span>, run-time checked=20
construction from a pointer is supported only for symmetry with <span style=
=3D"font-family:courier new,monospace">
optional_indirect</span>. It is entirely possible that it may be removed at=
some point=20
in the future.<br><br></div><div><span style=3D"font-family:courier new,mon=
ospace">indirect</span> and <span style=3D"font-family:courier new,monospac=
e">optional_indirect</span> are=20
primarily (implicitly) constructible from references. They are=20
(explicitly) constructible from pointers for convenience only. In my=20
view, this makes them sufficiently different from raw pointers that it=20
no longer makes sense to call them "pointer types". Indeed, the f=
actory=20
functions <span style=3D"font-family:monospace,monospace">make_indirect</sp=
an> and <span style=3D"font-family:monospace,monospace">make_optional_indir=
ect</span> do not have overloads that take pointers.<br></div><div><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"> Are there other differences?=
<br></blockquote><br></div><div>The
main difference is that <span style=3D"font-family:courier new,monospace">=
observer_ptr<T></span> has an "empty"/"null"=20
state, while <span style=3D"font-family:courier new,monospace">indirect<=
T></span> does not. I'd say this is a pretty big=20
difference. <span style=3D"font-family:courier new,monospace">optional_indi=
rect<T></span> is merely a=20
syntactic/memory-usage optimization of=20
<span style=3D"font-family:courier new,monospace">optional<indirect<T=
>></span>.<br><br>Aside from allowing implicit construction from and =
comparison with <span style=3D"font-family:courier new,monospace">T&</s=
pan>, the differences between <span style=3D"font-family:courier new,monosp=
ace">optional_indirect<T></span> and <span style=3D"font-family:couri=
er new,monospace">observer_ptr<T></span> are:<br><ul><li><span style=
=3D"font-family:courier new,monospace">optional_indirect</span> partially c=
opies the interface of <span style=3D"font-family:courier new,monospace">op=
tional</span> (use of <span style=3D"font-family:courier new,monospace">nul=
lopt</span>; <span style=3D"font-family:courier new,monospace">value</span>=
and <span style=3D"font-family:courier new,monospace">value_or</span>)</li=
><li><span style=3D"font-family:courier new,monospace">observer_ptr</span> =
partially copies the interface of <span style=3D"font-family:courier new,mo=
nospace">unique_ptr</span> (use of <span style=3D"font-family:courier new,m=
onospace">nullptr</span>; <span style=3D"font-family:courier new,monospace"=
>reset</span> and <span style=3D"font-family:courier new,monospace">release=
</span>)</li><li><span style=3D"font-family:courier new,monospace">optional=
_indirect<T></span> converts explicitly, not implicitly, to <span sty=
le=3D"font-family:courier new,monospace">T*</span> (implicit conversion doe=
sn't make sense for a non-pointer type)</li><li><span style=3D"font-fam=
ily:courier new,monospace">optional_indirect<T></span> has a <span st=
yle=3D"font-family:courier new,monospace">get_pointer</span> free function =
instead of a <span style=3D"font-family:courier new,monospace">get</span> m=
ember function (<span style=3D"font-family:courier new,monospace">get</span=
> doesn't make sense for a non-pointer type)<br></li></ul></div><div><b=
r></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"><div bgcolor=3D"#=
FFFFFF">
Should indirect<T> behave like an hypothetical
not_null<observer_ptr<T>>? or just not_null<T*>?
Note that I'm talking here of an hypothetical std::not_null class,
not the gsl;;not_null.<br></div></blockquote><div><br></div><div>Actual=
ly,
yes. That is probably a good way to put it to make people understand=20
what my design process has been. Take <span style=3D"font-family:courier ne=
w,monospace">observer_ptr<T></span> and=20
<span style=3D"font-family:courier new,monospace">not_null<observer_ptr&=
lt;T>></span> and then design from scratch what you consider to be th=
e=20
ideal interface for such types. I ended up with <span style=3D"font-family:=
courier new,monospace">indirect</span> and=20
<span style=3D"font-family:courier new,monospace">optional_indirect</span>.=
<br><br></div><div>You might have by now noticed the=20
big difference between these two designs; <span style=3D"font-family:courie=
r new,monospace">indirect</span> is given an "empty"=20
state by wrapping it in an <span style=3D"font-family:courier new,monospace=
">optional</span>, while <span style=3D"font-family:courier new,monospace">=
observer_ptr</span> has an "empty"=20
state that is suppressed by wrapping it in <span style=3D"font-family:couri=
er new,monospace">not_null</span>. There is something=20
that appeals to me aesthetically about adding functionality rather than=20
suppressing it. But the impact is more than aesthetic; consider how one wou=
ld use <span style=3D"font-family:courier new,monospace">make</span> functi=
ons and <span style=3D"font-family:courier new,monospace">auto</span> type =
deduction with both designs:<br><br></div><div style=3D"background-color:rg=
b(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-widt=
h:1px"><code><div><span style=3D"color:#008">auto</span><span style=3D"colo=
r:#000"> m_null </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> make_observer</span><span style=3D"color:#660">(</span><span s=
tyle=3D"color:#000">x</span><span style=3D"color:#660">);</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">// assuming `observer_pt=
r` supported construction from `T&`</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> =
n_null </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> make_not_null</span><span style=3D"color:#660">(</span><span style=3D"c=
olor:#000">a</span><span style=3D"color:#660">);</span><span style=3D"color=
:#000"> </span><span style=3D"color:#800">// presumably `make_not_null` per=
forms a run-time check</span></div></code></div><br><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px"><code><div><span style=3D"color:#008">auto</span><span sty=
le=3D"color:#000"> n_null </span><span style=3D"color:#660">=3D</span><span=
style=3D"color:#000"> make_indirect</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#000">x</span><span style=3D"color:#660">);</span><=
span style=3D"color:#000"> </span><span style=3D"color:#800">// no run-time=
check</span><span style=3D"color:#000"><br></span><span style=3D"color:#00=
8">auto</span><span style=3D"color:#000"> m_null </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> make_optional</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#000">x</span><span style=3D=
"color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#800">// no run-time check</span><span style=3D"color:#000"><br></span><=
/div></code></div><div><br>The run-time performance hit is a result of choo=
sing "maybe null" (i.e. <span style=3D"font-family:courier new,mo=
nospace">observer_ptr</span>) as the default. If you need another example, =
the protection provided by <span style=3D"font-family:courier new,monospace=
">not_null</span> can be circumvented:<br><br><div style=3D"background-colo=
r:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-=
width:1px"><code><div><span style=3D"color:#000">not_null</span><span style=
=3D"color:#660"><</span><span style=3D"color:#000">observer_ptr</span><s=
pan style=3D"color:#080"><int></span><span style=3D"color:#660">><=
/span><span style=3D"color:#000"> n_null </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> i</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"><br>observer_ptr</span><span style=3D"colo=
r:#080"><int></span><span style=3D"color:#660">&</span><span styl=
e=3D"color:#000"> obs </span><span style=3D"color:#660">=3D</span><span sty=
le=3D"color:#000"> n_null</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"><br>n_null </span><span style=3D"color:#660">=3D</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">nullptr</span>=
<span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span=
style=3D"color:#800">// `n_null` is now null</span></div></code></div><br>=
</div></div></div></div></blockquote><div><br>A slight correction (to avoid=
confusion):<br><br><div style=3D"background-color:rgb(250,250,250);border-=
color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><spa=
n style=3D"color:#000">not_null</span><span style=3D"color:#660"><</span=
><span style=3D"color:#000">observer_ptr</span><span style=3D"color:#080">&=
lt;int></span><span style=3D"color:#660">></span><span style=3D"color=
:#000"> n_null </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> i</span><span style=3D"color:#660">;</span><span style=3D"color=
:#000"><br>observer_ptr</span><span style=3D"color:#080"><int></span>=
<span style=3D"color:#660">&</span><span style=3D"color:#000"> m_null <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> n_nu=
ll</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
m_null </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#008">nullptr</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"> </span><span style=3D"color:#800">/=
/ `n_null` is now null</span></div></code></div><br>One addition point: it =
seems that <span style=3D"font-family: courier new,monospace;">gsl::not_nul=
l</span> converts only to <span style=3D"font-family: courier new,monospace=
;">T</span>, not <span style=3D"font-family: courier new,monospace;">T&=
</span>. Presumably this means it doesn't support move-only types. Perh=
aps <span style=3D"font-family: courier new,monospace;">not_null</span> cou=
ld be designed to avoid the above problem <i>and</i> support move-only type=
s. I'm not sure. At any rate, I think my point is clear.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote"><div>This is impossible to do with <span style=3D"font-fa=
mily:courier new,monospace">indirect</span>/<span style=3D"font-family:cour=
ier new,monospace">optional</span>.<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex"><div bgcolor=3D"#FFFFFF">
<blockquote type=3D"cite">
<div dir=3D"ltr"><span>
<div><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">
<div> Would optional_view<T> behave differently than
optional<view<T>>? If yes, when and why?<br>
<br>
<br>
</div>
</blockquote>
</span><div><br><span>
They are mostly functionally equivalent. As far as I can tell,
<span style=3D"font-family:courier new,monospace">optional_indire=
ct</span>
offers two advantages:<br>
<ol><li><span style=3D"font-family:courier new,monospace">optiona=
l<indirect<T>></span>
<i>probably</i> occupies twice as much memory as <span style=
=3D"font-family:courier new,monospace">optional_indirect<T></span>,
because the former needs to store a flag indicating
whether it contains a value, while the latter uses the
null pointer state to indicate emptiness. If <span style=3D"f=
ont-family:courier new,monospace">optional_indirect</span>
didn't exist, some people may not use <span style=3D"font=
-family:courier new,monospace">optional<indirect<T>></span>
just to avoid the additional memory cost compared to <span st=
yle=3D"font-family:courier new,monospace">T*</span>.<br>
</li></ol>
</span></div>
</div>
</blockquote>
We could have a specialization that preserves the interface and
improves the space performances, isn't it?<br>
I don't know how the committee fills about specializations like thi=
s
one. <br></div></blockquote><div><br></div><div>You cannot preserve the=
interface <i>and</i> improve space performance, because <span style=3D"fon=
t-family:monospace,monospace">optional<T>::operator*</span> and <span=
style=3D"font-family:monospace,monospace">optional<T>::value</span> =
both return <span style=3D"font-family:monospace,monospace">T&</span>; =
thus, <span style=3D"font-family:monospace,monospace">optional<T></sp=
an> must hold onto an instance of <span style=3D"font-family:monospace,mono=
space">T</span>.
Providing a specialization of the interface for <span style=3D"font-family=
:courier new,monospace">indirect</span> seems like a=20
bad idea to me. I like consistency; better to provide a separate type (<spa=
n style=3D"font-family:monospace,monospace">optional_indirect</span>).<br><=
/div><div>=C2=A0</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"><di=
v bgcolor=3D"#FFFFFF"><span>
=C2=A0<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<ol><li>There are situations when you have to dereference (<span =
style=3D"font-family:courier new,monospace">*</span>) an
<span style=3D"font-family:courier new,monospace">optional<=
;indirect<T>></span>
but not an <span style=3D"font-family:courier new,monospace">=
optional_indirect<T></span>, most
significantly when calling <span style=3D"font-family:courier=
new,monospace">indirect::operator*</span> or <span style=3D"font-family:co=
urier new,monospace">indirect::operator-></span>.
This is a syntactic nuisance. Compare this:</li></ol>
<div style=3D"margin-left:40px">
<div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px"><code>
<div><span style=3D"color:rgb(0,0,0)">foo f</span><span sty=
le=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>
optional</span><span style=3D"color:rgb(102,102,0)"><=
;</span><span style=3D"color:rgb(0,0,0)">indirect</span><span style=3D"colo=
r:rgb(0,136,0)"><foo></span><span style=3D"color:rgb(102,102,0)">>=
</span><span style=3D"color:rgb(0,0,0)"> o </span><span style=3D"color:rgb(=
102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> f</span><span style=
=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>
</span><span style=3D"color:rgb(102,102,0)">(*</span><spa=
n style=3D"color:rgb(0,0,0)">o</span><span style=3D"color:rgb(102,102,0)">)=
-></span><span style=3D"color:rgb(0,0,0)">bar
</span><span style=3D"color:rgb(102,102,0)">=3D</span><sp=
an style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">=
42</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:=
rgb(0,0,0)"><br>
</span></div>
</code></div>
</div>
</div>
</div>
</blockquote>
</span><code>You could use here </code>o->bar also</div></blockquote=
><div><br></div><div>I don't think you can. Chaining of the calls to <s=
pan style=3D"font-family:monospace,monospace">operator-></span> would on=
ly occur if <span style=3D"font-family:monospace,monospace">optional<ind=
irect<T>>::<wbr>operator-></span> returned <span style=3D"font-=
family:monospace,monospace">indirect<T>&</span> instead of <span =
style=3D"font-family:monospace,monospace">indirect<T>*</span>. <br></=
div><div>=C2=A0</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"><div=
bgcolor=3D"#FFFFFF"><span><br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>
<div style=3D"margin-left:40px">
<div style=3D"background-color:rgb(250,250,250);border-color:rg=
b(187,187,187);border-style:solid;border-width:1px"><code>
<div><span style=3D"color:rgb(0,0,0)">o</span><span style=
=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)">value</s=
pan><span style=3D"color:rgb(102,102,0)">()-></span><span style=3D"color=
:rgb(0,0,0)">bar
</span><span style=3D"color:rgb(102,102,0)">=3D</span><sp=
an style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,102)">=
42</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:=
rgb(0,0,0)"><br>
foo</span><span style=3D"color:rgb(102,102,0)">*</span>=
<span style=3D"color:rgb(0,0,0)"> p </span><span style=3D"color:rgb(102,102=
,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"colo=
r:rgb(0,0,136)">static_cast</span><span style=3D"color:rgb(102,102,0)"><=
</span><span style=3D"color:rgb(0,0,0)">foo</span><span style=3D"color:rgb(=
102,102,0)">*>(*</span><span style=3D"color:rgb(0,0,0)">o</span><span st=
yle=3D"color:rgb(102,102,0)">);</span></div>
</code></div>
</div>
<br>
<p style=3D"margin-left:40px">with this:</p>
<p style=3D"margin-left:40px"><br>
</p>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px"><code>
<div><span style=3D"color:rgb(0,0,0)">foo f</span><span style=
=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>
optional_indirect</span><span style=3D"color:rgb(0,136,0)=
"><foo></span><span style=3D"color:rgb(0,0,0)"> o </span><span style=
=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> f</sp=
an><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"color:rgb(0,=
0,0)"><br>
o</span><span style=3D"color:rgb(102,102,0)">-></span>=
<span style=3D"color:rgb(0,0,0)">bar </span><span style=3D"color:rgb(102,10=
2,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"col=
or:rgb(0,102,102)">42</span><span style=3D"color:rgb(102,102,0)">;</span><s=
pan style=3D"color:rgb(0,0,0)"><br>
o</span><span style=3D"color:rgb(102,102,0)">.</span><spa=
n style=3D"color:rgb(0,0,0)">value</span><span style=3D"color:rgb(102,102,0=
)">().</span><span style=3D"color:rgb(0,0,0)">bar </span><span style=3D"col=
or:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span=
style=3D"color:rgb(0,102,102)">42</span><span style=3D"color:rgb(102,102,0=
)">;</span><span style=3D"color:rgb(0,0,0)"><br>
foo</span><span style=3D"color:rgb(102,102,0)">*</span><s=
pan style=3D"color:rgb(0,0,0)"> p </span><span style=3D"color:rgb(102,102,0=
)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:=
rgb(0,0,136)">static_cast</span><span style=3D"color:rgb(102,102,0)"><</=
span><span style=3D"color:rgb(0,0,0)">foo</span><span style=3D"color:rgb(10=
2,102,0)">*>(</span><span style=3D"color:rgb(0,0,0)">o</span><span style=
=3D"color:rgb(102,102,0)">);</span></div>
</code></div>
<p style=3D"margin-left:40px"><br>
</p>
</div>
</div>
</blockquote></span>
I'm not sure yet to want two new class for just these differences,
but I can change.<br>
I believe it is worth seen how a better observer_ptr and an
orthogonal not_null wrapper behave together.<br></div></blockquote><div=
><br></div><div>You know by now why I consider <span style=3D"font-family:m=
onospace,monospace">indirect<T></span>/<span style=3D"font-family:mon=
ospace,monospace">optional<indirect<<wbr>T>></span> to be prefe=
rable to <span style=3D"font-family:monospace,monospace">optional_ptr<T&=
gt;</span>/<span style=3D"font-family:monospace,monospace">not_null<<wbr=
>optional_ptr<T>></span>. Sure, it's a shame that <span style=
=3D"font-family:monospace,monospace">optional<indirect<T>></spa=
n> is sub-optimal, but other than adding <span style=3D"font-family:monospa=
ce,monospace">optional_indirect<T></span>, I don't see any way ar=
ound it.<br></div><div>=C2=A0</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"><div bgcolor=3D"#FFFFFF">
<br>
Vicente<br>
<br>
</div><span>
-- <br>
You received this message because you are subscribed to a topic in the=20
Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0/unsubscribe" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/aK1IyB29tF0/unsubscribe';return t=
rue;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/aK1IyB29tF0/unsubscribe';return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/aK1IyB29tF0/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'mailto:std-proposals+unsubscribe@i=
socpp.org';return true;" onclick=3D"this.href=3D'mailto:std-proposa=
ls+unsubscribe@isocpp.org';return true;">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" rel=3D"nofollow" onmousedown=3D"this.href=3D'ma=
ilto:std-proposals@isocpp.org';return true;" onclick=3D"this.href=3D=
9;mailto:std-proposals@isocpp.org';return true;">std-proposals@isocpp.o=
rg</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/60f5b2af-99cc-7cfa-a123-617de4f2f274%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/60f5b2af-99cc-7cfa-a123-617de4f2f274%40w=
anadoo.fr?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" on=
click=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/60f5b2af-99cc-7cfa-a123-617de4f2f274%40wanadoo.fr?utm_medium\x3=
demail\x26utm_source\x3dfooter';return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/60f5b2af-99cc-7cfa-<wbr>a123-=
617de4f2f274%40wanadoo.fr</a><wbr>.<br>
</blockquote></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/f1c9384b-8ddf-42c6-b7a5-0028a382398a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1c9384b-8ddf-42c6-b7a5-0028a382398a=
%40isocpp.org</a>.<br />
------=_Part_2851_747205465.1479782147760--
------=_Part_2850_66208461.1479782147758--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Nov 2016 20:59:06 -0800 (PST)
Raw View
------=_Part_1245_433534652.1479790746305
Content-Type: multipart/alternative;
boundary="----=_Part_1246_1665587049.1479790746306"
------=_Part_1246_1665587049.1479790746306
Content-Type: text/plain; charset=UTF-8
Notations from the paper:
Since both types are very lightweight, the compiler should be able to
> easily elide the additional copy, so there should be no performance penalty
> for this design choice.
>
That's not how elision works. Elision is only allowed when a copy/move is
being used to *initialize* an object. Copying/moving into an *existing*
object can never be elided.
Now, I doubt that's going to impact performance, and compilers can use the
"as if" rule to compile away most of the stuff happening there (since
you're using the default assignment operator(s)). But you shouldn't refer
to that as elision.
Isn't indirect the same as std::reference_wrapper?
> ...
> They have different behaviour on assignment:
>
That is not true. `r = j` rebinds `reference_wrapper`. In fact,
`reference_wrapper` doesn't have an assignment operator for `T&` at all. `r
= j` relies instead on the implicit conversion of `j` to
`reference_wrapper<T>`. So yes, this will rebind the reference, as
demonstrated in this live example <http://ideone.com/CdO7Ur>.
On Monday, November 21, 2016 at 9:24:35 PM UTC-5, joseph....@gmail.com
wrote:
>
> On Tue, Nov 22, 2016 at 3:00 AM, Vicente J. Botet Escriba <
> vicent...@wanadoo.fr <javascript:>> wrote:
>
>> I agree that a not owning pointer should be initializable from a
>> reference.
>>
>
> I don't necessarily agree.
>
> I have come to realize that is counterproductive to think of a type as
> being "like a pointer" or "like a value" or "like a reference" during the
> design process; it is better that the semantics of a design be driven by
> the use case rather than such preconceptions.
>
Those "preconceptions" are *really important*. We have concepts like "value
type" and "pointer type" because they let us know how a type is supposed to
behave. They allow us to understand what it means to compare, copy, move,
etc such objects. By conforming to those expectations, it makes it easy for
users to know how to use them. Not only that, it allows users to build
systems that *rely* on those expectations.
`propagate_const` being a great example. It was designed for smart
pointers. Your types are logically smart pointers, but they don't conform
to the existing Concept for such types. And in many cases, there's no real
reason for them to not conform appropriately; what harm would there be in
adding `get` and `operator bool` to the interface of these types? We
shouldn't fix `propagate_const` to suit the needs of your types; we should
fix your types to be proper SmartPointers.
These concepts are not "counterproductive"; they are *crucial* for
communicating to users how a type is expected to behave. That way, users
don't have to look up in documentation what the exact behavior of various
operations are. A particular smart pointer may have added functionality, but there
is a clear paradigm for how a smart pointer is supposed to act.
You are developing types that have an amalgam of behavior, leading to a
design which acts like *no other type* in C++. That's not a good thing,
especially when semantically speaking, it is still just a smart pointer.
The overall design seems to be of a type optimized for being passed around
rather than being *used*. Here's what I mean.
If you put it in a function's parameter list, and a caller has a value of
type `T` they want to pass to that parameter, then they get to avoid having
to type `&value`. If you're passing one of these types to a function that
takes a `T&`, then you don't have to do `*id` in order to pass it in.
But in *almost every other use case*... you have to use it like a pointer.
If you want to access a member of the stored `T`, you have to use `*` or
`->`. If you want to do a comparison on the stored `T`s between two such
objects, you have to do `*id1 OP *id2` explicitly, just as you would if
they were pointers. And so on.
These types are like smart pointers that are really ashamed of being smart
pointers. So they have implicit conversions to/from T&, and they don't have
`get` like those *other* smart pointers. Which means that only thing you
gain from your design (relative to a true pointer interface) is that you
don't have quite so much use of `&` or `*` in your code.
Consistency is more important than convenience, *especially* when that
inconvenience is so trivial. Adding a few extra `&`s and `*`s in various
places is a small price to pay for having a consistent interface.
--
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/b3254811-fccd-427d-a884-f7f07b36bcb0%40isocpp.org.
------=_Part_1246_1665587049.1479790746306
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Notations from the paper:<br><br><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;">Since both types are very lightweight, the=
compiler should be able to=20
easily elide the additional copy, so there should be no performance=20
penalty for this design choice.<br></blockquote><br>That's not how elis=
ion works. Elision is only allowed when a copy/move is being used to <i>ini=
tialize</i> an object. Copying/moving into an <i>existing</i> object can ne=
ver be elided.<br><br>Now, I doubt that's going to impact performance, =
and compilers can use the "as if" rule to compile away most of th=
e stuff happening there (since you're using the default assignment oper=
ator(s)). But you shouldn't refer to that as elision.<br><br><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;">Isn't indirect the same=
as std::reference_wrapper?<br>...<br>They have different behaviour on assi=
gnment:<br></blockquote><br>That is not true. `r =3D j` rebinds `reference_=
wrapper`. In fact, `reference_wrapper` doesn't have an assignment opera=
tor for `T&` at all. `r =3D j` relies instead on the implicit conversio=
n of `j` to `reference_wrapper<T>`. So yes, this will rebind the refe=
rence, <a href=3D"http://ideone.com/CdO7Ur">as demonstrated in this live ex=
ample</a>.<br><br>On Monday, November 21, 2016 at 9:24:35 PM UTC-5, joseph.=
....@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Nov 22, 2016 at 3:00 AM, V=
icente J. Botet Escriba <span dir=3D"ltr"><<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"8olYiQHjAgAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">vicent...@wanadoo.fr</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF"><span>
<div>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
</div></blockquote></span></div></blockquote></div></div></div></bl=
ockquote><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></div><div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
I agree that a not owning pointer should be initializable from a
reference.<br></blockquote><div><br></div>I don't necessarily agree=
..<br><br>I
have come to realize that is counterproductive to think of a type
as being "like a pointer" or "like a value" or "l=
ike a reference"=20
during the design process; it=20
is better that the semantics of a design be driven by the use=20
case rather than such preconceptions.</div></div></div></div></blockquote><=
div><br>Those "preconceptions" are <i>really important</i>. We ha=
ve concepts like "value type" and "pointer type" becaus=
e they let us know how a type is supposed to behave. They allow us to under=
stand what it means to compare, copy, move, etc such objects. By conforming=
to those expectations, it makes it easy for users to know how to use them.=
Not only that, it allows users to build systems that <i>rely</i> on those =
expectations.<br><br>`propagate_const` being a great example. It was design=
ed for smart pointers. Your types are logically smart pointers, but they do=
n't conform to the existing Concept for such types. And in many cases, =
there's no real reason for them to not conform appropriately; what harm=
would there be in adding `get` and `operator bool` to the interface of the=
se types? We shouldn't fix `propagate_const` to suit the needs of your =
types; we should fix your types to be proper SmartPointers.<br><br>These co=
ncepts are not "counterproductive"; they are <i>crucial</i> for c=
ommunicating to users how a type is expected to behave. That way, users don=
't have to look up in documentation what the exact behavior of various =
operations are. A particular smart pointer may have added functionality, bu=
t<i> </i>there is a clear paradigm for how a smart pointer is supposed to a=
ct.<br><br>You are developing types that have an amalgam of behavior, leadi=
ng to a design which acts like <i>no other type</i> in C++. That's not =
a good thing, especially when semantically speaking, it is still just a sma=
rt pointer.<br><br>The overall design seems to be of a type optimized for b=
eing passed around rather than being <i>used</i>. Here's what I mean.<b=
r><br>If you put it in a function's parameter list, and a caller has a =
value of type `T` they want to pass to that parameter, then they get to avo=
id having to type `&value`. If you're passing one of these types to=
a function that takes a `T&`, then you don't have to do `*id` in o=
rder to pass it in.<br><br>But in <i>almost every other use case</i>... you=
have to use it like a pointer. If you want to access a member of the store=
d `T`, you have to use `*` or `->`. If you want to do a comparison on th=
e stored `T`s between two such objects, you have to do `*id1 OP *id2` expli=
citly, just as you would if they were pointers. And so on.<br><br>These typ=
es are like smart pointers that are really ashamed of being smart pointers.=
So they have implicit conversions to/from T&, and they don't have =
`get` like those <i>other</i> smart pointers. Which means that only thing y=
ou gain from your design (relative to a true pointer interface) is that you=
don't have quite so much use of `&` or `*` in your code.<br><br>Co=
nsistency is more important than convenience, <i>especially</i> when that i=
nconvenience is so trivial. Adding a few extra `&`s and `*`s in various=
places is a small price to pay for having a consistent interface.<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/b3254811-fccd-427d-a884-f7f07b36bcb0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b3254811-fccd-427d-a884-f7f07b36bcb0=
%40isocpp.org</a>.<br />
------=_Part_1246_1665587049.1479790746306--
------=_Part_1245_433534652.1479790746305--
.
Author: joseph.thomson@gmail.com
Date: Mon, 21 Nov 2016 23:40:14 -0800 (PST)
Raw View
------=_Part_9297_888316408.1479800414684
Content-Type: multipart/alternative;
boundary="----=_Part_9298_123238979.1479800414685"
------=_Part_9298_123238979.1479800414685
Content-Type: text/plain; charset=UTF-8
On Tuesday, 22 November 2016 12:59:06 UTC+8, Nicol Bolas wrote:
>
> Notations from the paper:
>
> Since both types are very lightweight, the compiler should be able to
>> easily elide the additional copy, so there should be no performance penalty
>> for this design choice.
>>
>
> That's not how elision works. Elision is only allowed when a copy/move is
> being used to *initialize* an object. Copying/moving into an *existing*
> object can never be elided.
>
> Now, I doubt that's going to impact performance, and compilers can use the
> "as if" rule to compile away most of the stuff happening there (since
> you're using the default assignment operator(s)). But you shouldn't refer
> to that as elision.
>
Thanks. That's handy to know.
Isn't indirect the same as std::reference_wrapper?
>> ...
>> They have different behaviour on assignment:
>>
>
> That is not true. `r = j` rebinds `reference_wrapper`. In fact,
> `reference_wrapper` doesn't have an assignment operator for `T&` at all. `r
> = j` relies instead on the implicit conversion of `j` to
> `reference_wrapper<T>`. So yes, this will rebind the reference, as
> demonstrated in this live example
> <http://www.google.com/url?q=http%3A%2F%2Fideone.com%2FCdO7Ur&sa=D&sntz=1&usg=AFQjCNFe1Ai_KtO4fJgUCnIhMP42tGxUnw>
> .
>
Ah okay. That explains the existence of reference_wrapper::get. I don't
know how I got that wrong. It's mainly the equality comparison behaviour
that is different then.
> On Monday, November 21, 2016 at 9:24:35 PM UTC-5, joseph....@gmail.com
> wrote:
>>
>> On Tue, Nov 22, 2016 at 3:00 AM, Vicente J. Botet Escriba <
>> vicent...@wanadoo.fr> wrote:
>>
>>> I agree that a not owning pointer should be initializable from a
>>> reference.
>>>
>>
>> I don't necessarily agree.
>>
>> I have come to realize that is counterproductive to think of a type as
>> being "like a pointer" or "like a value" or "like a reference" during the
>> design process; it is better that the semantics of a design be driven by
>> the use case rather than such preconceptions.
>>
>
> Those "preconceptions" are *really important*. We have concepts like
> "value type" and "pointer type" because they let us know how a type is
> supposed to behave. They allow us to understand what it means to compare,
> copy, move, etc such objects. By conforming to those expectations, it makes
> it easy for users to know how to use them. Not only that, it allows users
> to build systems that *rely* on those expectations.
>
I agree that it is very important to distinguish between the concepts of
"value" and "identity". A "value type" is one for which operator== tests
for equality of value and an "identity type" (for lack of a better term;
please excuse my use of it) is one for which operator== tests for equality
of identity (of the referenced object). These are distinct from
"pointer-like types" and "reference-like types" which are subjective
descriptions of types that appear to act sorta-kinda-mostly like pointer or
references. There are many instances of types which are "like a pointer" to
varying degrees, and I expect once "operator. overloading" is standardized,
there will be many more types which are "like a reference" to varying
degrees.
What I mean when I say that it is better to design around use cases, rather
than around the assumption that you are designing a type that is "like X
but does Y and Z", is that you will not be limited by preconceived notions
of what a type that "is like X" has to look like; I think this is what led
to observer_ptr being designed the way it is (like a resource managing
"smart" pointer, despite it not managing any resources). I'm not saying
throw all C++ design orthodoxy out of the window and mix whatever
behaviours you like just so that you can solve your narrow use case; just
don't be limited by existing notions of what metaphorical boxes types
should fit into. Don't be afraid to innovate!
`propagate_const` being a great example. It was designed for smart
> pointers. Your types are logically smart pointers, but they don't conform
> to the existing Concept for such types. And in many cases, there's no real
> reason for them to not conform appropriately; what harm would there be in
> adding `get` and `operator bool` to the interface of these types? We
> shouldn't fix `propagate_const` to suit the needs of your types; we should
> fix your types to be proper SmartPointers.
>
propagate_const has one job: to transform pointer-like indirection
semantics (used by T* and unique_ptr<T>) into value-like indirection
semantics (used by optional<T>). Nothing about this implies lifetime
management, which is what the current smart pointers do (it's what's so
"smart" about them, AFAIK). operator bool certainly is not required to do
this job, so why should indirect implement it when it otherwise makes no
sense to do so? Something like get *is* required; my issue is that the name
is too generic; I could be forced to concede on this point though. So I
disagree, propagate_const *does* need to be fixed: it should work with any
type that has pointer-like indirection semantics, and define a *minimal*
set of requirements on compatible types.
And no, I do not think my types are smart pointers, because they don't
manage any resources; however, I could also be forced to concede on the
"pointer-like" nature of indirect and choose a name with a _ptr suffix (if
this suffix indicates "pointer-like" status rather than "smart pointer"
status). Like I said, whether or not a type is "pointer-like" is
subjective. Is a pointer-like type which doesn't support pointer arithmetic
still a pointer-like type? How about one which is not copyable? What if it
is copyable but it does a deep copy of the underlying object? What about
one with value-like indirection semantics? What if it lacks a "null" state
and isn't contextually convertible to bool? What if it is constructible
from references as well as pointers? At what point is a type no longer
pointer-like?
These concepts are not "counterproductive"; they are *crucial* for
> communicating to users how a type is expected to behave. That way, users
> don't have to look up in documentation what the exact behavior of various
> operations are. A particular smart pointer may have added functionality, but there
> is a clear paradigm for how a smart pointer is supposed to act.
>
I like the principle of least surprise, but how on earth can anyone
implement new functionality without changing the semantics of existing
operations? Sure, don't go doing something really crazy, but unless you can
identify what aspects of my design are problematic, I'm not sure what
you're getting at here. unique_ptr changed the semantics of pointer
destruction; shared_ptr changed the semantics of pointer copying; optional
and propagate_const changed the semantics of the indirection operators
(previously only used by pointer-like types); the cloned_ptr type I've seen
discussed on this group changes the semantics of pointer copying *again*.
indirect adds reference-like construction semantics and removes the "null"
state (and therefore default construction and contextual conversion to bool);
the only question is whether or not a type missing these features should
still be considered "pointer-like" and whether this means it needs a "_ptr"
appended to its name. Perhaps someone needs to draw up a formal concept of
exactly what a "smart pointer" is, what exactly defines a "pointer-like
type" and which of these concepts corresponds to the "_ptr" suffix, and
then we can reach a consensus on naming.
You are developing types that have an amalgam of behavior, leading to a
> design which acts like *no other type* in C++. That's not a good thing,
> especially when semantically speaking, it is still just a smart pointer.
>
As I've mentioned, no type behaves like any other type. I don't see how
being different from existing types is a bad thing. And semantically, a
smart pointer manages the lifetime of the referenced object.
> The overall design seems to be of a type optimized for being passed around
> rather than being *used*. Here's what I mean.
>
> If you put it in a function's parameter list, and a caller has a value of
> type `T` they want to pass to that parameter, then they get to avoid having
> to type `&value`. If you're passing one of these types to a function that
> takes a `T&`, then you don't have to do `*id` in order to pass it in.
>
I recently removed implicit conversion from indirect<T> to T& because I
could see it causing problems. I need to update the documentation.
> But in *almost every other use case*... you have to use it like a
> pointer. If you want to access a member of the stored `T`, you have to use
> `*` or `->`. If you want to do a comparison on the stored `T`s between two
> such objects, you have to do `*id1 OP *id2` explicitly, just as you would
> if they were pointers. And so on.
>
I chose the name "indirect" because it implies pointer-like functionality
without giving the expectation of certain missing operations that are
commonly expected from pointers (namely, construction from pointer, the
"null" state and contextual conversion to bool). I worried that calling it
a "ptr" would be misleading and cause confusion and frustration. The aim is
not to have nicer syntax than pointers (though it is a nice side-effect);
the aim is to encourage code correctness and to convey intent through the
type system (the observer_ptr proposal calls such types "documentation
types").
> These types are like smart pointers that are really ashamed of being smart
> pointers. So they have implicit conversions to/from T&, and they don't have
> `get` like those *other* smart pointers. Which means that only thing you
> gain from your design (relative to a true pointer interface) is that you
> don't have quite so much use of `&` or `*` in your code.
>
What you gain from construction from T& instead of T* (though explicit
construction from T* is currently supported, though this isn't a done deal)
is conceptual and semantic correctness. As I mentioned in the informal
proposal, my logic is that implicit construction should be enabled if the
conversion is *always *(take my "always" with a pinch of salt; there are
usually exceptions) conceptually and semantically correct. Construction of
indirect from T* is not always *conceptually* correct because T* can
represent a wide range of things that aren't simple non-owning references
(e.g. pointer with ownership, array, iterator). Construction of indirect
from T* is not always *semantically* correct because it may be a null
pointer or may not refer to a valid object in memory (e.g. in the case of a
"past-the-end" iterator). Of course, T& may "be null" or refer to invalid
memory, but by this time the user has already invoked undefined behaviour
and all bets are off. The current smart pointers do not construct from T&
because references never represent the concept of dynamic resources to be
managed: pointers are used for resource management. But even smart pointers
do not allow implicit construction from T* because T* does not necessarily
represent an unmanaged dynamic resource of the correct type.
Of course, my reasoning may be totally off, so please point out any errors
I may have made.
> Consistency is more important than convenience, *especially* when that
> inconvenience is so trivial. Adding a few extra `&`s and `*`s in various
> places is a small price to pay for having a consistent interface.
>
As mentioned, syntactic convenience is secondary to code correctness in my
mind. I am not overly concerned with extra *'s and &'s (hence why I happily
just removed conversion from indirect to T&). And I agree that consistency
is paramount, but consistency to the point of "everything new must be
exactly like something that already exists" is taking it a step too far.
Thanks for taking the time to give feedback. It's really quite useful :-)
--
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/c67c064e-9c57-4abc-a4d9-e8e886387d4b%40isocpp.org.
------=_Part_9298_123238979.1479800414685
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, 22 November 2016 12:59:06 UTC+8, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Notatio=
ns from the paper:<br><br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>Since both types are very lightweight, the compiler should be able to=20
easily elide the additional copy, so there should be no performance=20
penalty for this design choice.<br></blockquote><br>That's not how elis=
ion works. Elision is only allowed when a copy/move is being used to <i>ini=
tialize</i> an object. Copying/moving into an <i>existing</i> object can ne=
ver be elided.<br><br>Now,
I doubt that's going to impact performance, and compilers can use the=
=20
"as if" rule to compile away most of the stuff happening there (s=
ince=20
you're using the default assignment operator(s)). But you shouldn't=
=20
refer to that as elision.<br></div></blockquote><div dir=3D"ltr">=C2=A0<br>=
Thanks. That's handy to know.<br><br><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;"><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I=
sn't indirect the same as std::reference_wrapper?<br>...<br>They have d=
ifferent behaviour on assignment:<br></blockquote><br>That
is not true. `r =3D j` rebinds `reference_wrapper`. In fact,=20
`reference_wrapper` doesn't have an assignment operator for `T&` at=
=20
all. `r =3D j` relies instead on the implicit conversion of `j` to=20
`reference_wrapper<T>`. So yes, this will rebind the reference, <a hr=
ef=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fideone.com%2FCdO7Ur&sa=
=3DD&sntz=3D1&usg=3DAFQjCNFe1Ai_KtO4fJgUCnIhMP42tGxUnw" target=3D"_=
blank" rel=3D"nofollow">as demonstrated in this live example</a>.<br></bloc=
kquote><div><br>Ah okay. That explains the existence of <span style=3D"font=
-family: courier new,monospace;">reference_wrapper::get</span>. I don't=
know how I got that wrong. It's mainly the equality comparison behavio=
ur that is different then.<br>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 2=
04); padding-left: 1ex;">On Monday, November 21, 2016 at 9:24:35 PM UTC-5, =
<a>joseph....@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Nov 22, 2016 at 3=
:00 AM, Vicente J. Botet Escriba <span dir=3D"ltr"><<a rel=3D"nofollow">=
vicent...@wanadoo.fr</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF"><span>
<div>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
</div></blockquote></span></div></blockquote></div></div></div></bl=
ockquote><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><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
I agree that a not owning pointer should be initializable from a
reference.<br></blockquote><div><br></div>I don't necessarily agree=
..<br><br>I
have come to realize that is counterproductive to think of a type
as being "like a pointer" or "like a value" or "l=
ike a reference"=20
during the design process; it=20
is better that the semantics of a design be driven by the use=20
case rather than such preconceptions.</div></div></div></div></blockquote><=
div><br>Those "preconceptions" are <i>really important</i>.
We have concepts like "value type" and "pointer type" =
because they let=20
us know how a type is supposed to behave. They allow us to understand=20
what it means to compare, copy, move, etc such objects. By conforming to
those expectations, it makes it easy for users to know how to use them.
Not only that, it allows users to build systems that <i>rely</i> on those =
expectations.<br></div></blockquote><div><br>I
agree that it is very important to distinguish between the concepts of=20
"value" and "identity". A "value type" is one=
for which <span style=3D"font-family: courier new,monospace;">operator=3D=
=3D</span>
tests for equality of value and an "identity type" (for lack of =
a=20
better term; please excuse my use of it) is=20
one for which <span style=3D"font-family: courier new,monospace;">operator=
=3D=3D</span>
tests for equality of identity (of the referenced object). These are=20
distinct from "pointer-like types" and "reference-like types=
" which are=20
subjective descriptions of types that appear to act sorta-kinda-mostly=20
like pointer or references. There are many instances of types which are &qu=
ot;like a pointer" to varying degrees, and I expect once "<span s=
tyle=3D"font-family: courier new,monospace;">operator.</span> overloading&q=
uot; is standardized, there will be many more types which are "like a =
reference" to varying degrees.<br><br>What I mean when I say that it i=
s=20
better to design around use cases, rather than around the assumption that y=
ou=20
are designing a type that is "like X but does Y and Z", is that y=
ou will=20
not be limited by preconceived notions of what a type that "is like X&=
quot;=20
has to look like; I think this is what led to observer_ptr being designed t=
he way it is (like a resource managing "smart" pointer, despite i=
t not managing any resources). I'm not saying throw all C++ design orth=
odoxy out of the=20
window and mix whatever behaviours you like just so that you can solve=20
your narrow use case; just don't be limited by existing notions of what=
metaphorical boxes types should fit into. Don't be afraid to innovate!=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><di=
v>`propagate_const`
being a great example. It was designed for smart pointers. Your types=20
are logically smart pointers, but they don't conform to the existing=20
Concept for such types. And in many cases, there's no real reason for=
=20
them to not conform appropriately; what harm would there be in adding=20
`get` and `operator bool` to the interface of these types? We shouldn't=
=20
fix `propagate_const` to suit the needs of your types; we should fix=20
your types to be proper SmartPointers.<br></div></blockquote><div><br><span=
style=3D"font-family: courier new,monospace;">propagate_const</span>
has one job: to transform pointer-like indirection semantics (used by <spa=
n style=3D"font-family: courier new,monospace;">T*</span> and <span style=
=3D"font-family: courier new,monospace;">unique_ptr<T></span>) into=
=20
value-like indirection semantics (used by <span style=3D"font-family: couri=
er new,monospace;">optional<T></span>). Nothing about this implies li=
fetime=20
management, which is what the current smart pointers do (it's what'=
s so=20
"smart" about them, AFAIK). <span style=3D"font-family: courier n=
ew,monospace;">operator bool</span> certainly is not required to do this jo=
b, so why should <span style=3D"font-family: courier new,monospace;">indire=
ct</span> implement it when it otherwise makes no sense to do so? Something=
like <span style=3D"font-family: courier new,monospace;">get</span> <i>is<=
/i>
required; my issue is that the name is too generic; I could be forced=20
to concede on this point though. So I disagree, <span style=3D"font-family:=
courier new,monospace;">propagate_const</span> <i>does</i>=20
need to be fixed: it should work with any type that has pointer-like indire=
ction semantics, and define a <i>minimal</i> set of requirements on compati=
ble types.<br><br>And no, I do not think my types are smart pointers, becau=
se they don't manage any resources; however, I=20
could also be forced to concede on the "pointer-like" nature of <=
span style=3D"font-family: courier new,monospace;">indirect</span> and choo=
se a name with a <span style=3D"font-family: courier new,monospace;">_ptr</=
span>=20
suffix (if this suffix indicates "pointer-like" status rather tha=
n "smart pointer" status). Like I said, whether or not a type is =
"pointer-like" is subjective. Is a pointer-like type which doesn&=
#39;t support pointer arithmetic still a pointer-like type? How about one w=
hich is not copyable? What if it is copyable but it does a deep copy of the=
underlying object? What about one with value-like indirection semantics? W=
hat if it lacks a "null" state and isn't contextually convert=
ible to bool? What if it is constructible from references as well as pointe=
rs? At what point is a type no longer pointer-like?<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;"><div>These concepts are not=
"counterproductive"; they are <i>crucial</i>
for communicating to users how a type is expected to behave. That way,=20
users don't have to look up in documentation what the exact behavior of=
=20
various operations are. A particular smart pointer may have added=20
functionality, but<i> </i>there is a clear paradigm for how a smart pointer=
is supposed to act.<br></div></blockquote><div><br>I like the principle of=
least surprise, but how on earth can anyone implement new functionality wi=
thout changing the semantics of existing operations? Sure, don't go doi=
ng something really crazy, but unless you can identify what aspects of my d=
esign are problematic, I'm not sure what you're getting at here. <s=
pan style=3D"font-family: courier new,monospace;">unique_ptr</span> changed=
the semantics of pointer destruction; <span style=3D"font-family: courier =
new,monospace;">shared_ptr</span> changed the semantics of pointer copying;=
<span style=3D"font-family: courier new,monospace;">optional</span> and <s=
pan style=3D"font-family: courier new,monospace;">propagate_const</span> ch=
anged the semantics of the indirection operators (previously only used by p=
ointer-like types); the <span style=3D"font-family: courier new,monospace;"=
>cloned_ptr</span> type I've seen discussed on this group changes the s=
emantics of pointer copying <i>again</i>.<br><br><span style=3D"font-family=
: courier new,monospace;">indirect</span> adds reference-like construction =
semantics and removes the "null" state (and therefore default con=
struction and contextual conversion to <span style=3D"font-family: courier =
new,monospace;">bool</span>); the only question is whether or not a type mi=
ssing these features should still be considered "pointer-like" an=
d whether this means it needs a "<span style=3D"font-family: courier n=
ew,monospace;">_ptr</span>" appended to its name. Perhaps someone need=
s to draw up a formal concept of exactly what a "smart pointer" i=
s, what exactly defines a "pointer-like type" and which of these =
concepts corresponds to the "<span style=3D"font-family: courier new,m=
onospace;">_ptr</span>" suffix, and then we can reach a consensus on n=
aming.<br><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=
;"><div>You are developing types that have an amalgam of behavior, leading =
to a design which acts like <i>no other type</i> in C++. That's not a g=
ood thing, especially when semantically speaking, it is still just a smart =
pointer.<br></div></blockquote><div><br>As I've mentioned, no type beha=
ves like any other type. I don't see how being different from existing =
types is a bad thing. And semantically, a smart pointer manages the lifetim=
e of the referenced object.<br>=C2=A0</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;"><div>The overall design seems to be of a type opt=
imized for being passed around rather than being <i>used</i>. Here's wh=
at I mean.<br><br>If
you put it in a function's parameter list, and a caller has a value of=
=20
type `T` they want to pass to that parameter, then they get to avoid=20
having to type `&value`. If you're passing one of these types to a=
=20
function that takes a `T&`, then you don't have to do `*id` in orde=
r
to pass it in.<br></div></blockquote><div><br>I recently removed implicit =
conversion from <span style=3D"font-family: courier new,monospace;">indirec=
t<T></span> to <span style=3D"font-family: courier new,monospace;">T&=
amp;</span> because I could see it causing problems. I need to update the d=
ocumentation.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-=
left: 1ex;"><div>But in <i>almost every other use case</i>... you=20
have to use it like a pointer. If you want to access a member of the=20
stored `T`, you have to use `*` or `->`. If you want to do a=20
comparison on the stored `T`s between two such objects, you have to do=20
`*id1 OP *id2` explicitly, just as you would if they were pointers. And=20
so on.<br></div></blockquote><div><br>I chose the name "<span style=3D=
"font-family: courier new,monospace;">indirect</span>" because it impl=
ies pointer-like functionality without giving the expectation of certain mi=
ssing operations that are commonly expected from pointers (namely, construc=
tion from pointer, the "null" state and contextual conversion to=
<span style=3D"font-family: courier new,monospace;">bool</span>). I worrie=
d that calling it a "<span style=3D"font-family: courier new,monospace=
;">ptr</span>" would be misleading and cause confusion and frustration=
.. The aim is not to have nicer syntax than pointers (though it is a nice si=
de-effect); the aim is to encourage code correctness and to convey intent t=
hrough the type system (the <span style=3D"font-family: courier new,monospa=
ce;">observer_ptr</span> proposal calls such types "documentation type=
s").<br>=C2=A0</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;"><div>These types are like smart pointers that are really=20
ashamed of being smart pointers. So they have implicit conversions=20
to/from T&, and they don't have `get` like those <i>other</i> smart=
=20
pointers. Which means that only thing you gain from your design=20
(relative to a true pointer interface) is that you don't have quite so=
=20
much use of `&` or `*` in your code.<br></div></blockquote><div><br>Wha=
t you gain from construction from <span style=3D"font-family: courier new,m=
onospace;">T&</span> instead of <span style=3D"font-family: courier new=
,monospace;">T*</span> (though explicit construction from <span style=3D"fo=
nt-family: courier new,monospace;">T*</span> is currently supported, though=
this isn't a done deal) is conceptual and semantic correctness. As I m=
entioned in the informal proposal, my logic is that implicit construction s=
hould be enabled if the conversion is <i>always </i>(take my "always&q=
uot; with a pinch of salt; there are usually exceptions) conceptually and s=
emantically correct. Construction of <span style=3D"font-family: courier ne=
w,monospace;">indirect</span> from<span style=3D"font-family: courier new,m=
onospace;"> T*</span> is not always <i>conceptually</i> correct because <sp=
an style=3D"font-family: courier new,monospace;">T*</span> can represent a =
wide range of things that aren't simple non-owning references (e.g. poi=
nter with ownership, array, iterator). Construction of <span style=3D"font-=
family: courier new,monospace;">indirect</span> from <span style=3D"font-fa=
mily: courier new,monospace;">T*</span> is not always <i>semantically</i> c=
orrect because it may be a null pointer or may not refer to a valid object =
in memory (e.g. in the case of a "past-the-end" iterator). Of cou=
rse, <span style=3D"font-family: courier new,monospace;">T&</span> may =
"be null" or refer to invalid memory, but by this time the user h=
as already invoked undefined behaviour and all bets are off. The current sm=
art pointers do not construct from <span style=3D"font-family: courier new,=
monospace;">T&</span> because references never represent the concept of=
dynamic resources to be managed: pointers are used for resource management=
.. But even smart pointers do not allow implicit construction from <span sty=
le=3D"font-family: courier new,monospace;">T*</span> because <span style=3D=
"font-family: courier new,monospace;">T*</span> does not necessarily repres=
ent an unmanaged dynamic resource of the correct type.<br><br>Of course, my=
reasoning may be totally off, so please point out any errors I may have ma=
de.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;=
"><div>Consistency is more important than convenience, <i>especially</i>
when that inconvenience is so trivial. Adding a few extra `&`s and=20
`*`s in various places is a small price to pay for having a consistent=20
interface.<br></div></blockquote><div><br>As mentioned, syntactic convenien=
ce is secondary to code correctness in my mind. I am not overly concerned w=
ith extra <span style=3D"font-family: courier new,monospace;">*</span>'=
s and <span style=3D"font-family: courier new,monospace;">&</span>'=
s (hence why I happily just removed conversion from <span style=3D"font-fam=
ily: courier new,monospace;">indirect</span> to <span style=3D"font-family:=
courier new,monospace;">T&</span>). And I agree that consistency is pa=
ramount, but consistency to the point of "everything new must be exact=
ly like something that already exists" is taking it a step too far.<br=
><br>Thanks for taking the time to give feedback. It's really quite use=
ful :-)<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" 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/c67c064e-9c57-4abc-a4d9-e8e886387d4b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c67c064e-9c57-4abc-a4d9-e8e886387d4b=
%40isocpp.org</a>.<br />
------=_Part_9298_123238979.1479800414685--
------=_Part_9297_888316408.1479800414684--
.
Author: joseph.thomson@gmail.com
Date: Mon, 21 Nov 2016 23:59:20 -0800 (PST)
Raw View
------=_Part_9607_297140447.1479801560114
Content-Type: multipart/alternative;
boundary="----=_Part_9608_1180984962.1479801560114"
------=_Part_9608_1180984962.1479801560114
Content-Type: text/plain; charset=UTF-8
On Tuesday, 22 November 2016 15:40:14 UTC+8, joseph....@gmail.com wrote:
>
> On Tuesday, 22 November 2016 12:59:06 UTC+8, Nicol Bolas wrote:
>>
>> Notations from the paper:
>>
>> Since both types are very lightweight, the compiler should be able to
>>> easily elide the additional copy, so there should be no performance penalty
>>> for this design choice.
>>>
>>
>> That's not how elision works. Elision is only allowed when a copy/move is
>> being used to *initialize* an object. Copying/moving into an *existing*
>> object can never be elided.
>>
>> Now, I doubt that's going to impact performance, and compilers can use
>> the "as if" rule to compile away most of the stuff happening there (since
>> you're using the default assignment operator(s)). But you shouldn't refer
>> to that as elision.
>>
>
> Thanks. That's handy to know.
>
> Isn't indirect the same as std::reference_wrapper?
>>> ...
>>> They have different behaviour on assignment:
>>>
>>
>> That is not true. `r = j` rebinds `reference_wrapper`. In fact,
>> `reference_wrapper` doesn't have an assignment operator for `T&` at all. `r
>> = j` relies instead on the implicit conversion of `j` to
>> `reference_wrapper<T>`. So yes, this will rebind the reference, as
>> demonstrated in this live example
>> <http://www.google.com/url?q=http%3A%2F%2Fideone.com%2FCdO7Ur&sa=D&sntz=1&usg=AFQjCNFe1Ai_KtO4fJgUCnIhMP42tGxUnw>
>> .
>>
>
> Ah okay. That explains the existence of reference_wrapper::get. I don't
> know how I got that wrong. It's mainly the equality comparison behaviour
> that is different then.
>
>
>> On Monday, November 21, 2016 at 9:24:35 PM UTC-5, joseph....@gmail.com
>> wrote:
>>>
>>> On Tue, Nov 22, 2016 at 3:00 AM, Vicente J. Botet Escriba <
>>> vicent...@wanadoo.fr> wrote:
>>>
>>>> I agree that a not owning pointer should be initializable from a
>>>> reference.
>>>>
>>>
>>> I don't necessarily agree.
>>>
>>> I have come to realize that is counterproductive to think of a type as
>>> being "like a pointer" or "like a value" or "like a reference" during the
>>> design process; it is better that the semantics of a design be driven by
>>> the use case rather than such preconceptions.
>>>
>>
>> Those "preconceptions" are *really important*. We have concepts like
>> "value type" and "pointer type" because they let us know how a type is
>> supposed to behave. They allow us to understand what it means to compare,
>> copy, move, etc such objects. By conforming to those expectations, it makes
>> it easy for users to know how to use them. Not only that, it allows users
>> to build systems that *rely* on those expectations.
>>
>
> I agree that it is very important to distinguish between the concepts of
> "value" and "identity". A "value type" is one for which operator== tests
> for equality of value and an "identity type" (for lack of a better term;
> please excuse my use of it) is one for which operator== tests for
> equality of identity (of the referenced object). These are distinct from
> "pointer-like types" and "reference-like types" which are subjective
> descriptions of types that appear to act sorta-kinda-mostly like pointer or
> references. There are many instances of types which are "like a pointer" to
> varying degrees, and I expect once "operator. overloading" is
> standardized, there will be many more types which are "like a reference" to
> varying degrees.
>
> What I mean when I say that it is better to design around use cases,
> rather than around the assumption that you are designing a type that is
> "like X but does Y and Z", is that you will not be limited by preconceived
> notions of what a type that "is like X" has to look like; I think this is
> what led to observer_ptr being designed the way it is (like a resource
> managing "smart" pointer, despite it not managing any resources). I'm not
> saying throw all C++ design orthodoxy out of the window and mix whatever
> behaviours you like just so that you can solve your narrow use case; just
> don't be limited by existing notions of what metaphorical boxes types
> should fit into. Don't be afraid to innovate!
>
> `propagate_const` being a great example. It was designed for smart
>> pointers. Your types are logically smart pointers, but they don't conform
>> to the existing Concept for such types. And in many cases, there's no real
>> reason for them to not conform appropriately; what harm would there be in
>> adding `get` and `operator bool` to the interface of these types? We
>> shouldn't fix `propagate_const` to suit the needs of your types; we should
>> fix your types to be proper SmartPointers.
>>
>
> propagate_const has one job: to transform pointer-like indirection
> semantics (used by T* and unique_ptr<T>) into value-like indirection
> semantics (used by optional<T>). Nothing about this implies lifetime
> management, which is what the current smart pointers do (it's what's so
> "smart" about them, AFAIK). operator bool certainly is not required to do
> this job, so why should indirect implement it when it otherwise makes no
> sense to do so? Something like get *is* required; my issue is that the
> name is too generic; I could be forced to concede on this point though. So
> I disagree, propagate_const *does* need to be fixed: it should work with
> any type that has pointer-like indirection semantics, and define a
> *minimal* set of requirements on compatible types.
>
> And no, I do not think my types are smart pointers, because they don't
> manage any resources; however, I could also be forced to concede on the
> "pointer-like" nature of indirect and choose a name with a _ptr suffix
> (if this suffix indicates "pointer-like" status rather than "smart pointer"
> status). Like I said, whether or not a type is "pointer-like" is
> subjective. Is a pointer-like type which doesn't support pointer arithmetic
> still a pointer-like type? How about one which is not copyable? What if it
> is copyable but it does a deep copy of the underlying object? What about
> one with value-like indirection semantics? What if it lacks a "null" state
> and isn't contextually convertible to bool? What if it is constructible
> from references as well as pointers? At what point is a type no longer
> pointer-like?
>
> These concepts are not "counterproductive"; they are *crucial* for
>> communicating to users how a type is expected to behave. That way, users
>> don't have to look up in documentation what the exact behavior of various
>> operations are. A particular smart pointer may have added functionality, but there
>> is a clear paradigm for how a smart pointer is supposed to act.
>>
>
> I like the principle of least surprise, but how on earth can anyone
> implement new functionality without changing the semantics of existing
> operations? Sure, don't go doing something really crazy, but unless you can
> identify what aspects of my design are problematic, I'm not sure what
> you're getting at here. unique_ptr changed the semantics of pointer
> destruction; shared_ptr changed the semantics of pointer copying; optional
> and propagate_const changed the semantics of the indirection operators
> (previously only used by pointer-like types); the cloned_ptr type I've
> seen discussed on this group changes the semantics of pointer copying
> *again*.
>
> indirect adds reference-like construction semantics and removes the
> "null" state (and therefore default construction and contextual conversion
> to bool); the only question is whether or not a type missing these
> features should still be considered "pointer-like" and whether this means
> it needs a "_ptr" appended to its name. Perhaps someone needs to draw up
> a formal concept of exactly what a "smart pointer" is, what exactly defines
> a "pointer-like type" and which of these concepts corresponds to the "_ptr"
> suffix, and then we can reach a consensus on naming.
>
> You are developing types that have an amalgam of behavior, leading to a
>> design which acts like *no other type* in C++. That's not a good thing,
>> especially when semantically speaking, it is still just a smart pointer.
>>
>
> As I've mentioned, no type behaves like any other type. I don't see how
> being different from existing types is a bad thing. And semantically, a
> smart pointer manages the lifetime of the referenced object.
>
>
>> The overall design seems to be of a type optimized for being passed
>> around rather than being *used*. Here's what I mean.
>>
>> If you put it in a function's parameter list, and a caller has a value of
>> type `T` they want to pass to that parameter, then they get to avoid having
>> to type `&value`. If you're passing one of these types to a function that
>> takes a `T&`, then you don't have to do `*id` in order to pass it in.
>>
>
> I recently removed implicit conversion from indirect<T> to T& because I
> could see it causing problems. I need to update the documentation.
>
>
>> But in *almost every other use case*... you have to use it like a
>> pointer. If you want to access a member of the stored `T`, you have to use
>> `*` or `->`. If you want to do a comparison on the stored `T`s between two
>> such objects, you have to do `*id1 OP *id2` explicitly, just as you would
>> if they were pointers. And so on.
>>
>
> I chose the name "indirect" because it implies pointer-like functionality
> without giving the expectation of certain missing operations that are
> commonly expected from pointers (namely, construction from pointer, the
> "null" state and contextual conversion to bool). I worried that calling
> it a "ptr" would be misleading and cause confusion and frustration. The
> aim is not to have nicer syntax than pointers (though it is a nice
> side-effect); the aim is to encourage code correctness and to convey intent
> through the type system (the observer_ptr proposal calls such types
> "documentation types").
>
Uh, "vocabulary types". Sorry.
>
>
>> These types are like smart pointers that are really ashamed of being
>> smart pointers. So they have implicit conversions to/from T&, and they
>> don't have `get` like those *other* smart pointers. Which means that
>> only thing you gain from your design (relative to a true pointer interface)
>> is that you don't have quite so much use of `&` or `*` in your code.
>>
>
> What you gain from construction from T& instead of T* (though explicit
> construction from T* is currently supported, though this isn't a done
> deal) is conceptual and semantic correctness. As I mentioned in the
> informal proposal, my logic is that implicit construction should be enabled
> if the conversion is *always *(take my "always" with a pinch of salt;
> there are usually exceptions) conceptually and semantically correct.
> Construction of indirect from T* is not always *conceptually* correct
> because T* can represent a wide range of things that aren't simple
> non-owning references (e.g. pointer with ownership, array, iterator).
> Construction of indirect from T* is not always *semantically* correct
> because it may be a null pointer or may not refer to a valid object in
> memory (e.g. in the case of a "past-the-end" iterator). Of course, T& may
> "be null" or refer to invalid memory, but by this time the user has already
> invoked undefined behaviour and all bets are off. The current smart
> pointers do not construct from T& because references never represent the
> concept of dynamic resources to be managed: pointers are used for resource
> management. But even smart pointers do not allow implicit construction from
> T* because T* does not necessarily represent an unmanaged dynamic
> resource of the correct type.
>
> Of course, my reasoning may be totally off, so please point out any errors
> I may have made.
>
>
>> Consistency is more important than convenience, *especially* when that
>> inconvenience is so trivial. Adding a few extra `&`s and `*`s in various
>> places is a small price to pay for having a consistent interface.
>>
>
> As mentioned, syntactic convenience is secondary to code correctness in my
> mind. I am not overly concerned with extra *'s and &'s (hence why I
> happily just removed conversion from indirect to T&). And I agree that
> consistency is paramount, but consistency to the point of "everything new
> must be exactly like something that already exists" is taking it a step too
> far.
>
> Thanks for taking the time to give feedback. It's really quite useful :-)
>
--
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/a6b4801a-41f7-41bf-9d89-ff6427c1d406%40isocpp.org.
------=_Part_9608_1180984962.1479801560114
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, 22 November 2016 15:40:14 UTC+8, josep=
h....@gmail.com 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 Tuesday, 22 November 2016 12:59:06 UTC+8, Nicol Bolas 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">Notations from the =
paper:<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Since both =
types are very lightweight, the compiler should be able to=20
easily elide the additional copy, so there should be no performance=20
penalty for this design choice.<br></blockquote><br>That's not how elis=
ion works. Elision is only allowed when a copy/move is being used to <i>ini=
tialize</i> an object. Copying/moving into an <i>existing</i> object can ne=
ver be elided.<br><br>Now,
I doubt that's going to impact performance, and compilers can use the=
=20
"as if" rule to compile away most of the stuff happening there (s=
ince=20
you're using the default assignment operator(s)). But you shouldn't=
=20
refer to that as elision.<br></div></blockquote><div dir=3D"ltr">=C2=A0<br>=
Thanks. That's handy to know.<br><br><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Isn't=
indirect the same as std::reference_wrapper?<br>...<br>They have different=
behaviour on assignment:<br></blockquote><br>That
is not true. `r =3D j` rebinds `reference_wrapper`. In fact,=20
`reference_wrapper` doesn't have an assignment operator for `T&` at=
=20
all. `r =3D j` relies instead on the implicit conversion of `j` to=20
`reference_wrapper<T>`. So yes, this will rebind the reference, <a hr=
ef=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2Fideone.com%2FCdO7Ur&sa=
=3DD&sntz=3D1&usg=3DAFQjCNFe1Ai_KtO4fJgUCnIhMP42tGxUnw" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.c=
om/url?q\x3dhttp%3A%2F%2Fideone.com%2FCdO7Ur\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNFe1Ai_KtO4fJgUCnIhMP42tGxUnw';return true;" onclick=3D"this.h=
ref=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fideone.com%2FCdO7Ur\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFe1Ai_KtO4fJgUCnIhMP42tGxUnw';r=
eturn true;">as demonstrated in this live example</a>.<br></blockquote><div=
><br>Ah okay. That explains the existence of <span style=3D"font-family:cou=
rier new,monospace">reference_wrapper::get</span>. I don't know how I g=
ot that wrong. It's mainly the equality comparison behaviour that is di=
fferent then.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">On Monday, November 21, 2016 at 9:24:35 PM UTC-5, <a>joseph....@gmail.c=
om</a> wrote:<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>=
<div class=3D"gmail_quote">On Tue, Nov 22, 2016 at 3:00 AM, Vicente J. Bote=
t Escriba <span dir=3D"ltr"><<a rel=3D"nofollow">vicent...@wanadoo.fr</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF"><span>
<div>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr">
</div></blockquote></span></div></blockquote></div></div></div></bl=
ockquote><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><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
I agree that a not owning pointer should be initializable from a
reference.<br></blockquote><div><br></div>I don't necessarily agree=
..<br><br>I
have come to realize that is counterproductive to think of a type
as being "like a pointer" or "like a value" or "l=
ike a reference"=20
during the design process; it=20
is better that the semantics of a design be driven by the use=20
case rather than such preconceptions.</div></div></div></div></blockquote><=
div><br>Those "preconceptions" are <i>really important</i>.
We have concepts like "value type" and "pointer type" =
because they let=20
us know how a type is supposed to behave. They allow us to understand=20
what it means to compare, copy, move, etc such objects. By conforming to
those expectations, it makes it easy for users to know how to use them.
Not only that, it allows users to build systems that <i>rely</i> on those =
expectations.<br></div></blockquote><div><br>I
agree that it is very important to distinguish between the concepts of=20
"value" and "identity". A "value type" is one=
for which <span style=3D"font-family:courier new,monospace">operator=3D=3D=
</span>
tests for equality of value and an "identity type" (for lack of =
a=20
better term; please excuse my use of it) is=20
one for which <span style=3D"font-family:courier new,monospace">operator=3D=
=3D</span>
tests for equality of identity (of the referenced object). These are=20
distinct from "pointer-like types" and "reference-like types=
" which are=20
subjective descriptions of types that appear to act sorta-kinda-mostly=20
like pointer or references. There are many instances of types which are &qu=
ot;like a pointer" to varying degrees, and I expect once "<span s=
tyle=3D"font-family:courier new,monospace">operator.</span> overloading&quo=
t; is standardized, there will be many more types which are "like a re=
ference" to varying degrees.<br><br>What I mean when I say that it is=
=20
better to design around use cases, rather than around the assumption that y=
ou=20
are designing a type that is "like X but does Y and Z", is that y=
ou will=20
not be limited by preconceived notions of what a type that "is like X&=
quot;=20
has to look like; I think this is what led to observer_ptr being designed t=
he way it is (like a resource managing "smart" pointer, despite i=
t not managing any resources). I'm not saying throw all C++ design orth=
odoxy out of the=20
window and mix whatever behaviours you like just so that you can solve=20
your narrow use case; just don't be limited by existing notions of what=
metaphorical boxes types should fit into. Don't be afraid to innovate!=
<br><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"><div>`propa=
gate_const`
being a great example. It was designed for smart pointers. Your types=20
are logically smart pointers, but they don't conform to the existing=20
Concept for such types. And in many cases, there's no real reason for=
=20
them to not conform appropriately; what harm would there be in adding=20
`get` and `operator bool` to the interface of these types? We shouldn't=
=20
fix `propagate_const` to suit the needs of your types; we should fix=20
your types to be proper SmartPointers.<br></div></blockquote><div><br><span=
style=3D"font-family:courier new,monospace">propagate_const</span>
has one job: to transform pointer-like indirection semantics (used by <spa=
n style=3D"font-family:courier new,monospace">T*</span> and <span style=3D"=
font-family:courier new,monospace">unique_ptr<T></span>) into=20
value-like indirection semantics (used by <span style=3D"font-family:courie=
r new,monospace">optional<T></span>). Nothing about this implies life=
time=20
management, which is what the current smart pointers do (it's what'=
s so=20
"smart" about them, AFAIK). <span style=3D"font-family:courier ne=
w,monospace">operator bool</span> certainly is not required to do this job,=
so why should <span style=3D"font-family:courier new,monospace">indirect</=
span> implement it when it otherwise makes no sense to do so? Something lik=
e <span style=3D"font-family:courier new,monospace">get</span> <i>is</i>
required; my issue is that the name is too generic; I could be forced=20
to concede on this point though. So I disagree, <span style=3D"font-family:=
courier new,monospace">propagate_const</span> <i>does</i>=20
need to be fixed: it should work with any type that has pointer-like indire=
ction semantics, and define a <i>minimal</i> set of requirements on compati=
ble types.<br><br>And no, I do not think my types are smart pointers, becau=
se they don't manage any resources; however, I=20
could also be forced to concede on the "pointer-like" nature of <=
span style=3D"font-family:courier new,monospace">indirect</span> and choose=
a name with a <span style=3D"font-family:courier new,monospace">_ptr</span=
>=20
suffix (if this suffix indicates "pointer-like" status rather tha=
n "smart pointer" status). Like I said, whether or not a type is =
"pointer-like" is subjective. Is a pointer-like type which doesn&=
#39;t support pointer arithmetic still a pointer-like type? How about one w=
hich is not copyable? What if it is copyable but it does a deep copy of the=
underlying object? What about one with value-like indirection semantics? W=
hat if it lacks a "null" state and isn't contextually convert=
ible to bool? What if it is constructible from references as well as pointe=
rs? At what point is a type no longer pointer-like?<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div>These concepts are not "c=
ounterproductive"; they are <i>crucial</i>
for communicating to users how a type is expected to behave. That way,=20
users don't have to look up in documentation what the exact behavior of=
=20
various operations are. A particular smart pointer may have added=20
functionality, but<i> </i>there is a clear paradigm for how a smart pointer=
is supposed to act.<br></div></blockquote><div><br>I like the principle of=
least surprise, but how on earth can anyone implement new functionality wi=
thout changing the semantics of existing operations? Sure, don't go doi=
ng something really crazy, but unless you can identify what aspects of my d=
esign are problematic, I'm not sure what you're getting at here. <s=
pan style=3D"font-family:courier new,monospace">unique_ptr</span> changed t=
he semantics of pointer destruction; <span style=3D"font-family:courier new=
,monospace">shared_ptr</span> changed the semantics of pointer copying; <sp=
an style=3D"font-family:courier new,monospace">optional</span> and <span st=
yle=3D"font-family:courier new,monospace">propagate_const</span> changed th=
e semantics of the indirection operators (previously only used by pointer-l=
ike types); the <span style=3D"font-family:courier new,monospace">cloned_pt=
r</span> type I've seen discussed on this group changes the semantics o=
f pointer copying <i>again</i>.<br><br><span style=3D"font-family:courier n=
ew,monospace">indirect</span> adds reference-like construction semantics an=
d removes the "null" state (and therefore default construction an=
d contextual conversion to <span style=3D"font-family:courier new,monospace=
">bool</span>); the only question is whether or not a type missing these fe=
atures should still be considered "pointer-like" and whether this=
means it needs a "<span style=3D"font-family:courier new,monospace">_=
ptr</span>" appended to its name. Perhaps someone needs to draw up a f=
ormal concept of exactly what a "smart pointer" is, what exactly =
defines a "pointer-like type" and which of these concepts corresp=
onds to the "<span style=3D"font-family:courier new,monospace">_ptr</s=
pan>" suffix, and then we can reach a consensus on naming.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div>You are developing=
types that have an amalgam of behavior, leading to a design which acts lik=
e <i>no other type</i> in C++. That's not a good thing, especially when=
semantically speaking, it is still just a smart pointer.<br></div></blockq=
uote><div><br>As I've mentioned, no type behaves like any other type. I=
don't see how being different from existing types is a bad thing. And =
semantically, a smart pointer manages the lifetime of the referenced object=
..<br>=C2=A0</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"><div>The=
overall design seems to be of a type optimized for being passed around rat=
her than being <i>used</i>. Here's what I mean.<br><br>If
you put it in a function's parameter list, and a caller has a value of=
=20
type `T` they want to pass to that parameter, then they get to avoid=20
having to type `&value`. If you're passing one of these types to a=
=20
function that takes a `T&`, then you don't have to do `*id` in orde=
r
to pass it in.<br></div></blockquote><div><br>I recently removed implicit =
conversion from <span style=3D"font-family:courier new,monospace">indirect&=
lt;T></span> to <span style=3D"font-family:courier new,monospace">T&=
</span> because I could see it causing problems. I need to update the docum=
entation.<br>=C2=A0</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">=
<div>But in <i>almost every other use case</i>... you=20
have to use it like a pointer. If you want to access a member of the=20
stored `T`, you have to use `*` or `->`. If you want to do a=20
comparison on the stored `T`s between two such objects, you have to do=20
`*id1 OP *id2` explicitly, just as you would if they were pointers. And=20
so on.<br></div></blockquote><div><br>I chose the name "<span style=3D=
"font-family:courier new,monospace">indirect</span>" because it implie=
s pointer-like functionality without giving the expectation of certain miss=
ing operations that are commonly expected from pointers (namely, constructi=
on from pointer, the "null" state and contextual conversion to <=
span style=3D"font-family:courier new,monospace">bool</span>). I worried th=
at calling it a "<span style=3D"font-family:courier new,monospace">ptr=
</span>" would be misleading and cause confusion and frustration. The =
aim is not to have nicer syntax than pointers (though it is a nice side-eff=
ect); the aim is to encourage code correctness and to convey intent through=
the type system (the <span style=3D"font-family:courier new,monospace">obs=
erver_ptr</span> proposal calls such types "documentation types")=
..<br></div></div></div></blockquote><div><br>Uh, "vocabulary types&quo=
t;. Sorry.<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;"><div=
dir=3D"ltr"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><div>These types are like smart pointers that are rea=
lly=20
ashamed of being smart pointers. So they have implicit conversions=20
to/from T&, and they don't have `get` like those <i>other</i> smart=
=20
pointers. Which means that only thing you gain from your design=20
(relative to a true pointer interface) is that you don't have quite so=
=20
much use of `&` or `*` in your code.<br></div></blockquote><div><br>Wha=
t you gain from construction from <span style=3D"font-family:courier new,mo=
nospace">T&</span> instead of <span style=3D"font-family:courier new,mo=
nospace">T*</span> (though explicit construction from <span style=3D"font-f=
amily:courier new,monospace">T*</span> is currently supported, though this =
isn't a done deal) is conceptual and semantic correctness. As I mention=
ed in the informal proposal, my logic is that implicit construction should =
be enabled if the conversion is <i>always </i>(take my "always" w=
ith a pinch of salt; there are usually exceptions) conceptually and semanti=
cally correct. Construction of <span style=3D"font-family:courier new,monos=
pace">indirect</span> from<span style=3D"font-family:courier new,monospace"=
> T*</span> is not always <i>conceptually</i> correct because <span style=
=3D"font-family:courier new,monospace">T*</span> can represent a wide range=
of things that aren't simple non-owning references (e.g. pointer with =
ownership, array, iterator). Construction of <span style=3D"font-family:cou=
rier new,monospace">indirect</span> from <span style=3D"font-family:courier=
new,monospace">T*</span> is not always <i>semantically</i> correct because=
it may be a null pointer or may not refer to a valid object in memory (e.g=
.. in the case of a "past-the-end" iterator). Of course, <span sty=
le=3D"font-family:courier new,monospace">T&</span> may "be null&qu=
ot; or refer to invalid memory, but by this time the user has already invok=
ed undefined behaviour and all bets are off. The current smart pointers do =
not construct from <span style=3D"font-family:courier new,monospace">T&=
</span> because references never represent the concept of dynamic resources=
to be managed: pointers are used for resource management. But even smart p=
ointers do not allow implicit construction from <span style=3D"font-family:=
courier new,monospace">T*</span> because <span style=3D"font-family:courier=
new,monospace">T*</span> does not necessarily represent an unmanaged dynam=
ic resource of the correct type.<br><br>Of course, my reasoning may be tota=
lly off, so please point out any errors I may have made.<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div>Consistency is more imp=
ortant than convenience, <i>especially</i>
when that inconvenience is so trivial. Adding a few extra `&`s and=20
`*`s in various places is a small price to pay for having a consistent=20
interface.<br></div></blockquote><div><br>As mentioned, syntactic convenien=
ce is secondary to code correctness in my mind. I am not overly concerned w=
ith extra <span style=3D"font-family:courier new,monospace">*</span>'s =
and <span style=3D"font-family:courier new,monospace">&</span>'s (h=
ence why I happily just removed conversion from <span style=3D"font-family:=
courier new,monospace">indirect</span> to <span style=3D"font-family:courie=
r new,monospace">T&</span>). And I agree that consistency is paramount,=
but consistency to the point of "everything new must be exactly like =
something that already exists" is taking it a step too far.<br><br>Tha=
nks for taking the time to give feedback. It's really quite useful :-)<=
br></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" 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/a6b4801a-41f7-41bf-9d89-ff6427c1d406%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a6b4801a-41f7-41bf-9d89-ff6427c1d406=
%40isocpp.org</a>.<br />
------=_Part_9608_1180984962.1479801560114--
------=_Part_9607_297140447.1479801560114--
.