Topic: `box` - A container which may hold exactly zero
Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 5 Jun 2018 08:21:52 +0200
Raw View
2018-06-05 8:19 GMT+02:00 Nicole Mazzuca <npmazzuca@gmail.com>:
> I've often wished for a container that can hold exactly one object -
> something
> like `std::unique_ptr`, but with value and container semantics. I want de=
ep
> compare, deep copy, etc. However, there isn't any container that fits the
> bill
> in the current standard library. I'd like to gauge interest in having a t=
ype
> like this.
The term "container" confused me a bit, but other than that, you
should take a look whether std::optional meets your requirements
already.
- Daniel
> I've called it `box`, because that's often how these things are referred =
to
> -
> Rust has `Box<T>`, Racket has `box`, Java has "Boxing". The name is
> completely
> up for bikeshedding. The interface is on my github, here:
>
> https://github.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L50
>
> The sample implementation of the member functions is here:
>
> https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl.h
>
> I apologize for the mostly untested code, as well as any weird things tha=
t
> clang-format may have done! At this point, it's just a proof of concept.
> However, that is intended to be the "final" interface, so if there's
> anything in
> there you object to, or anything you'd like to see added, please speak up=
!
>
> I'm not certain this would be good for standardization, which is why I've
> placed
> it in the `ublib` namespace. I think, personally, it would be very useful
> for
> things like recursive types, as well as whenever one wants to put somethi=
ng
> behind a pointer, for whatever reason. `std::unique_ptr` is a useful tool=
,
> but
> it's fairly poor when one wants a proper C++ container type.
>
> Some notes:
>
> First - I'm not sure whether `reverse_iterator` should be a
> `std::reverse_iterator` - it works just fine as a normal `iterator`, give=
n
> that
> there can either be zero or one elements, and a reversed range of zero or
> one
> elements is the same range. I felt as though `rbegin` and the like should=
be
> provided, however, as there's no reason not to have them.
>
> Second - This doesn't follow the requirements for AllocatorAwareContainer=
-
> it's
> a Container, which is aware of allocators, but it uses the new
> `std::allocator_arg_t` style interface.
>
> Third - Comparison is a lexicographic comparison.
>
> And I think that's it! If you have any questions, please ask away!
>
> Thanks for your time,
>
> Nicole Mazzuca
>
> --
> 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/f111e16b-4ab=
0-4f98-899a-f58133223ccc%40isocpp.org.
--=20
________________________________
SavedURI :Show URLShow URLSavedURI :
SavedURI :Hide URLHide URLSavedURI :
https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN4ilL=
E.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD=
-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D1395770=
800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2=
fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0=
_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D1=
395770800154
________________________________
--=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/CAGNvRgB5Yi2AvKHzjGi_3iKtHTtDpvj%2B7%3D-%2BfCz30=
QJ_aTS3JA%40mail.gmail.com.
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Mon, 4 Jun 2018 23:42:02 -0700 (PDT)
Raw View
------=_Part_38453_565274514.1528180922272
Content-Type: multipart/alternative;
boundary="----=_Part_38454_930116788.1528180922272"
------=_Part_38454_930116788.1528180922272
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I'm sorry, I realized I didn't cover my motivation very well. The intention=
=20
is
for three things in this container -
First: that it is a container. This should act like a value type, and it=20
should
have things like iterators and the like, and it should have deep copy and
compare semantics. It's different from `std::unique_ptr` in this way.
Second: It must be heap allocated - this is useful for, say, PIMPL, or=20
recursive
types, where `optional` is absolutely not an option.
Third: It should not have any polymorphic overhead, and it should act like =
a
container when it comes to allocators - this rules out something like
`polymorphic_value`.
Here's some example code using it for the pimpl idiom:
https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0
On Monday, June 4, 2018 at 11:21:55 PM UTC-7, Daniel Kr=C3=BCgler wrote:
>
> 2018-06-05 8:19 GMT+02:00 Nicole Mazzuca <npma...@gmail.com <javascript:>=
>:=20
>
> > I've often wished for a container that can hold exactly one object -=20
> > something=20
> > like `std::unique_ptr`, but with value and container semantics. I want=
=20
> deep=20
> > compare, deep copy, etc. However, there isn't any container that fits=
=20
> the=20
> > bill=20
> > in the current standard library. I'd like to gauge interest in having a=
=20
> type=20
> > like this.=20
>
> The term "container" confused me a bit, but other than that, you=20
> should take a look whether std::optional meets your requirements=20
> already.=20
>
> - Daniel=20
>
> > I've called it `box`, because that's often how these things are referre=
d=20
> to=20
> > -=20
> > Rust has `Box<T>`, Racket has `box`, Java has "Boxing". The name is=20
> > completely=20
> > up for bikeshedding. The interface is on my github, here:=20
> >=20
> > https://github.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L50=
=20
> >=20
> > The sample implementation of the member functions is here:=20
> >=20
> >=20
> https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl.h=
=20
> >=20
> > I apologize for the mostly untested code, as well as any weird things=
=20
> that=20
> > clang-format may have done! At this point, it's just a proof of concept=
..=20
> > However, that is intended to be the "final" interface, so if there's=20
> > anything in=20
> > there you object to, or anything you'd like to see added, please speak=
=20
> up!=20
> >=20
> > I'm not certain this would be good for standardization, which is why=20
> I've=20
> > placed=20
> > it in the `ublib` namespace. I think, personally, it would be very=20
> useful=20
> > for=20
> > things like recursive types, as well as whenever one wants to put=20
> something=20
> > behind a pointer, for whatever reason. `std::unique_ptr` is a useful=20
> tool,=20
> > but=20
> > it's fairly poor when one wants a proper C++ container type.=20
> >=20
> > Some notes:=20
> >=20
> > First - I'm not sure whether `reverse_iterator` should be a=20
> > `std::reverse_iterator` - it works just fine as a normal `iterator`,=20
> given=20
> > that=20
> > there can either be zero or one elements, and a reversed range of zero=
=20
> or=20
> > one=20
> > elements is the same range. I felt as though `rbegin` and the like=20
> should be=20
> > provided, however, as there's no reason not to have them.=20
> >=20
> > Second - This doesn't follow the requirements for=20
> AllocatorAwareContainer -=20
> > it's=20
> > a Container, which is aware of allocators, but it uses the new=20
> > `std::allocator_arg_t` style interface.=20
> >=20
> > Third - Comparison is a lexicographic comparison.=20
> >=20
> > And I think that's it! If you have any questions, please ask away!=20
> >=20
> > Thanks for your time,=20
> >=20
> > Nicole Mazzuca=20
> >=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit=20
> >=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f111e16b-4ab=
0-4f98-899a-f58133223ccc%40isocpp.org.=20
>
>
>
>
> --=20
>
> ________________________________=20
> SavedURI :Show URLShow URLSavedURI :=20
> SavedURI :Hide URLHide URLSavedURI :=20
>
> https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN4i=
lLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_=
AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D13957=
70800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LE=
t2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m=
_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=
=3D1395770800154=20
> ________________________________=20
>
--=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/f7af42f8-b74b-4f13-bde4-452b746558b2%40isocpp.or=
g.
------=_Part_38454_930116788.1528180922272
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm sorry, I realized I didn't cover my motivation=
very well. The intention is<br>for three things in this container -<br><br=
>First: that it is a container. This should act like a value type, and it s=
hould<br>have things like iterators and the like, and it should have deep c=
opy and<br>compare semantics. It's different from `std::unique_ptr` in =
this way.<br><br>Second: It must be heap allocated - this is useful for, sa=
y, PIMPL, or recursive<br>types, where `optional` is absolutely not an opti=
on.<br><br>Third: It should not have any polymorphic overhead, and it shoul=
d act like a<br>container when it comes to allocators - this rules out some=
thing like<br>`polymorphic_value`.<br><br>Here's some example code usin=
g it for the pimpl idiom:<br><br>https://gist.github.com/ubsan/d71f7a13a069=
be0107be2842444c53f0<br><br><br>On Monday, June 4, 2018 at 11:21:55 PM UTC-=
7, Daniel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2=
018-06-05 8:19 GMT+02:00 Nicole Mazzuca <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"IlW4abMjBAAJ" rel=3D"nofollow" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hre=
f=3D'javascript:';return true;">npma...@gmail.com</a>>:
<br>> I've often wished for a container that can hold exactly one ob=
ject -
<br>> something
<br>> like `std::unique_ptr`, but with value and container semantics. I =
want deep
<br>> compare, deep copy, etc. However, there isn't any container th=
at fits the
<br>> bill
<br>> in the current standard library. I'd like to gauge interest in=
having a type
<br>> like this.
<br>
<br>The term "container" confused me a bit, but other than that, =
you
<br>should take a look whether std::optional meets your requirements
<br>already.
<br>
<br>- Daniel
<br>
<br>> I've called it `box`, because that's often how these thing=
s are referred to
<br>> -
<br>> Rust has `Box<T>`, Racket has `box`, Java has "Boxing&q=
uot;. The name is
<br>> completely
<br>> up for bikeshedding. The interface is on my github, here:
<br>>
<br>> <a href=3D"https://github.com/ubsan/ublib/blob/master/box/include/=
ublib/box.h#L50" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2=
Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2Fbox.h%23L50\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA';return true;" o=
nclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgi=
thub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2Fbox.h%23=
L50\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA=
9;;return true;">https://github.com/ubsan/<wbr>ublib/blob/master/box/includ=
e/<wbr>ublib/box.h#L50</a>
<br>>
<br>> The sample implementation of the member functions is here:
<br>>
<br>> <a href=3D"https://github.com/ubsan/ublib/blob/master/box/include/=
ublib/__box_impl.h" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsa=
n%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2F__box_impl.h\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83Pgg';return true=
;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2F__bo=
x_impl.h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83P=
gg';return true;">https://github.com/ubsan/<wbr>ublib/blob/master/box/i=
nclude/<wbr>ublib/__box_impl.h</a>
<br>>
<br>> I apologize for the mostly untested code, as well as any weird thi=
ngs that
<br>> clang-format may have done! At this point, it's just a proof o=
f concept.
<br>> However, that is intended to be the "final" interface, s=
o if there's
<br>> anything in
<br>> there you object to, or anything you'd like to see added, plea=
se speak up!
<br>>
<br>> I'm not certain this would be good for standardization, which =
is why I've
<br>> placed
<br>> it in the `ublib` namespace. I think, personally, it would be very=
useful
<br>> for
<br>> things like recursive types, as well as whenever one wants to put =
something
<br>> behind a pointer, for whatever reason. `std::unique_ptr` is a usef=
ul tool,
<br>> but
<br>> it's fairly poor when one wants a proper C++ container type.
<br>>
<br>> Some notes:
<br>>
<br>> First - I'm not sure whether `reverse_iterator` should be a
<br>> `std::reverse_iterator` - it works just fine as a normal `iterator=
`, given
<br>> that
<br>> there can either be zero or one elements, and a reversed range of =
zero or
<br>> one
<br>> elements is the same range. I felt as though `rbegin` and the like=
should be
<br>> provided, however, as there's no reason not to have them.
<br>>
<br>> Second - This doesn't follow the requirements for AllocatorAwa=
reContainer -
<br>> it's
<br>> a Container, which is aware of allocators, but it uses the new
<br>> `std::allocator_arg_t` style interface.
<br>>
<br>> Third - Comparison is a lexicographic comparison.
<br>>
<br>> And I think that's it! If you have any questions, please ask a=
way!
<br>>
<br>> Thanks for your time,
<br>>
<br>> Nicole Mazzuca
<br>>
<br>> --
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"IlW4abMjBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"IlW4abMjBAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">std-pr...@isocpp.org</a>.
<br>> To view this discussion on the web visit
<br>> <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/f111e16b-4ab0-4f98-899a-f58133223ccc%40isocpp.org" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f111e16b-4ab0-4f98-899a-f58133223ccc%40i=
socpp.org';return true;" onclick=3D"this.href=3D'https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/f111e16b-4ab0-4f98-899a-f5813322=
3ccc%40isocpp.org';return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/f111e16b-4ab0-4f98-<wbr>899a-f58133223ccc%=
40isocpp.org</a><wbr>.
<br>
<br>
<br>
<br>--=20
<br>
<br>______________________________<wbr>__
<br>SavedURI :Show URLShow URLSavedURI :
<br>SavedURI :Hide URLHide URLSavedURI :
<br><a href=3D"https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.mai=
n.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBB=
RgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?r=
andom=3D1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgma=
il.main.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVA=
OBGeBBRgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4k=
uOWA?random=3D1395770800154" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'https://mail.google.com/_/scs/mail-static/_/js/k\x3dgm=
ail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnelj6j997_NLil29=
vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9wv1JKZMABIG3Ak=
8ViC4kuOWA?random\x3d1395770800154https://mail.google.com/_/scs/mail-static=
/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnel=
j6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9w=
v1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154';return true;" onclick=
=3D"this.href=3D'https://mail.google.com/_/scs/mail-static/_/js/k\x3dgm=
ail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnelj6j997_NLil29=
vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9wv1JKZMABIG3Ak=
8ViC4kuOWA?random\x3d1395770800154https://mail.google.com/_/scs/mail-static=
/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnel=
j6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9w=
v1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154';return true;">https://=
mail.google.com/_/scs/<wbr>mail-static/_/js/k=3Dgmail.main.<wbr>de.LEt2fN4i=
lLE.O/m=3Dm_i,t,it/<wbr>am=3DOCMOBiHj9kJxhnelj6j997_<wbr>NLil29vVAOBGeBBRgJ=
wD-m_0_8B_<wbr>AD-qOEw/rt=3Dh/d=3D1/rs=3D<wbr>AItRSTODy9wv1JKZMABIG3Ak8ViC4=
k<wbr>uOWA?random=3D<wbr>1395770800154https://mail.<wbr>google.com/_/scs/ma=
il-static/_<wbr>/js/k=3Dgmail.main.de.<wbr>LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3D=
<wbr>OCMOBiHj9kJxhnelj6j997_<wbr>NLil29vVAOBGeBBRgJwD-m_0_8B_<wbr>AD-qOEw/r=
t=3Dh/d=3D1/rs=3D<wbr>AItRSTODy9wv1JKZMABIG3Ak8ViC4k<wbr>uOWA?random=3D1395=
770800154</a>
<br>______________________________<wbr>__
<br></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/f7af42f8-b74b-4f13-bde4-452b746558b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7af42f8-b74b-4f13-bde4-452b746558b2=
%40isocpp.org</a>.<br />
------=_Part_38454_930116788.1528180922272--
------=_Part_38453_565274514.1528180922272--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 5 Jun 2018 09:03:28 +0200
Raw View
--000000000000e69b93056ddfa725
Content-Type: text/plain; charset="UTF-8"
On Tue, Jun 5, 2018 at 8:42 AM Nicole Mazzuca <npmazzuca@gmail.com> wrote:
> First: that it is a container. This should act like a value type, and it
> should
> have things like iterators and the like, and it should have deep copy and
> compare semantics. It's different from `std::unique_ptr` in this way.
>
> Second: It must be heap allocated - this is useful for, say, PIMPL, or
> recursive
> types, where `optional` is absolutely not an option.
>
> Third: It should not have any polymorphic overhead, and it should act like
> a
> container when it comes to allocators - this rules out something like
> `polymorphic_value`.
>
> Here's some example code using it for the pimpl idiom:
>
> https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0
>
Do you have a sample implementation?
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BMqrntZJnJK8FjrhSOG8UjjsJJOC3uxJp27Nu%3DLAYiG5Q%40mail.gmail.com.
--000000000000e69b93056ddfa725
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jun 5, 2018 at 8:42 AM Nicole Mazzuca <<a href=
=3D"mailto:npmazzuca@gmail.com">npmazzuca@gmail.com</a>> wrote:<br><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">First=
: that it is a container. This should act like a value type, and it should<=
br>have things like iterators and the like, and it should have deep copy an=
d<br>compare semantics. It's different from `std::unique_ptr` in this w=
ay.<br><br>Second: It must be heap allocated - this is useful for, say, PIM=
PL, or recursive<br>types, where `optional` is absolutely not an option.<br=
><br>Third: It should not have any polymorphic overhead, and it should act =
like a<br>container when it comes to allocators - this rules out something =
like<br>`polymorphic_value`.<br><br>Here's some example code using it f=
or the pimpl idiom:<br><br><a href=3D"https://gist.github.com/ubsan/d71f7a1=
3a069be0107be2842444c53f0" target=3D"_blank">https://gist.github.com/ubsan/=
d71f7a13a069be0107be2842444c53f0</a></div></blockquote><div><br></div><div>=
Do you have a sample implementation?</div></div>-- <br><div dir=3D"ltr" cla=
ss=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">=
<div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mail=
to:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilov=
erlord.com</a>> =C2=A0+1-847-691-1404</div></div></div></div></div></div=
>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAGg_6%2BMqrntZJnJK8FjrhSOG8UjjsJJOC3=
uxJp27Nu%3DLAYiG5Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMqrn=
tZJnJK8FjrhSOG8UjjsJJOC3uxJp27Nu%3DLAYiG5Q%40mail.gmail.com</a>.<br />
--000000000000e69b93056ddfa725--
.
Author: Corentin <corentin.jabot@gmail.com>
Date: Tue, 5 Jun 2018 09:24:28 +0200
Raw View
--0000000000007ddf8d056ddff122
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
How would it compare to:
std::array<T,1>
std::vector<T>(1) - I guess you want to avoid to pay for the two extra
members ?
Le mar. 5 juin 2018 =C3=A0 09:04, Nevin Liber <nevin@eviloverlord.com> a =
=C3=A9crit :
> On Tue, Jun 5, 2018 at 8:42 AM Nicole Mazzuca <npmazzuca@gmail.com> wrote=
:
>
>> First: that it is a container. This should act like a value type, and it
>> should
>> have things like iterators and the like, and it should have deep copy an=
d
>> compare semantics. It's different from `std::unique_ptr` in this way.
>>
>> Second: It must be heap allocated - this is useful for, say, PIMPL, or
>> recursive
>> types, where `optional` is absolutely not an option.
>>
>> Third: It should not have any polymorphic overhead, and it should act
>> like a
>> container when it comes to allocators - this rules out something like
>> `polymorphic_value`.
>>
>> Here's some example code using it for the pimpl idiom:
>>
>> https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0
>>
>
> Do you have a sample implementation?
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
> <+1%20847-691-1404>
>
> --
> 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/CAGg_6%2BMqr=
ntZJnJK8FjrhSOG8UjjsJJOC3uxJp27Nu%3DLAYiG5Q%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMq=
rntZJnJK8FjrhSOG8UjjsJJOC3uxJp27Nu%3DLAYiG5Q%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>
--=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/CA%2BOm%2BSjy6Anp3_qqrZMYVguifiB7RRvSTPobSgOk-of=
jybnd0Q%40mail.gmail.com.
--0000000000007ddf8d056ddff122
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div>How would it compare to:</div><div>std::array<=
T,1></div><div>std::vector<T>(1) - I guess you want to avoid to pa=
y for the two extra members ?</div><div><br></div><div><br></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0mar. 5 juin 2018 =C3=A0=C2=A0=
09:04, Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com">nevin@evil=
overlord.com</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr">On Tue, Jun 5, 2018 at 8:42 AM Nicole Mazzuca <<a=
href=3D"mailto:npmazzuca@gmail.com" target=3D"_blank">npmazzuca@gmail.com<=
/a>> wrote:<br></div><div dir=3D"ltr"><div class=3D"gmail_quote"><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">First: that it is a container. Thi=
s should act like a value type, and it should<br>have things like iterators=
and the like, and it should have deep copy and<br>compare semantics. It=
9;s different from `std::unique_ptr` in this way.<br><br>Second: It must be=
heap allocated - this is useful for, say, PIMPL, or recursive<br>types, wh=
ere `optional` is absolutely not an option.<br><br>Third: It should not hav=
e any polymorphic overhead, and it should act like a<br>container when it c=
omes to allocators - this rules out something like<br>`polymorphic_value`.<=
br><br>Here's some example code using it for the pimpl idiom:<br><br><a=
href=3D"https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0" ta=
rget=3D"_blank">https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c5=
3f0</a></div></blockquote><div><br></div></div></div><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div>Do you have a sample implementation?</div></div>=
-- <br><div dir=3D"ltr" class=3D"m_7553726337684703938gmail_signature" data=
-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=
=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>> =C2=A0<a=
href=3D"tel:+1%20847-691-1404" value=3D"+18476911404" target=3D"_blank">+1=
-847-691-1404</a></div></div></div></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMqrntZJnJK8FjrhSOG8UjjsJJOC3=
uxJp27Nu%3DLAYiG5Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAGg_6%2BMqrntZJnJK8FjrhSOG8UjjsJJOC3uxJp27Nu%3DLAYiG5Q%40mail.gma=
il.com</a>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjy6Anp3_qqrZMYVguifiB7RRvS=
TPobSgOk-ofjybnd0Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BSjy=
6Anp3_qqrZMYVguifiB7RRvSTPobSgOk-ofjybnd0Q%40mail.gmail.com</a>.<br />
--0000000000007ddf8d056ddff122--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 5 Jun 2018 09:26:31 +0200
Raw View
--000000000000567ef5056ddffa81
Content-Type: text/plain; charset="UTF-8"
On Tue, Jun 5, 2018 at 9:24 AM Corentin <corentin.jabot@gmail.com> wrote:
>
> How would it compare to:
> std::array<T,1>
>
Array models "exactly one element", not "at most one element".
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
--
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/CAGg_6%2BMXQ_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com.
--000000000000567ef5056ddffa81
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Jun 5, 2018 at 9:24 AM Corentin <<a href=3D"mai=
lto:corentin.jabot@gmail.com">corentin.jabot@gmail.com</a>> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
r><div>How would it compare to:</div><div>std::array<T,1></div></div>=
</blockquote><div><br></div><div>Array models "exactly one element&quo=
t;, not "at most one element".</div><div>--=C2=A0<br></div></div>=
<div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signatur=
e"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" =
Liber=C2=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"=
_blank">nevin@eviloverlord.com</a>> =C2=A0+1-847-691-1404</div></div></d=
iv></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/CAGg_6%2BMXQ_fSxv89egbfVHOPMcFFsU79F%=
2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
MXQ_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com</a>.<br=
/>
--000000000000567ef5056ddffa81--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 5 Jun 2018 11:13:32 +0200
Raw View
--0000000000008a32f7056de17757
Content-Type: text/plain; charset="UTF-8"
This idea raises an interesting question.
Why not make every object iterable?
Here's a quick and dirty implementation of std::begin and std::end for a
std::optional
http://coliru.stacked-crooked.com/a/7588796d45879675
It seems to me that there is no reason that std::begin(int&) could not
return a std::iterator_of_one_thing<int>, for example.
Logically, it seems to me that a singular object is just a special case of
an array of zero or more objects.
On Tue, 5 Jun 2018 at 09:27, Nevin Liber <nevin@eviloverlord.com> wrote:
> On Tue, Jun 5, 2018 at 9:24 AM Corentin <corentin.jabot@gmail.com> wrote:
>
>>
>> How would it compare to:
>> std::array<T,1>
>>
>
> Array models "exactly one element", not "at most one element".
> --
> Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> +1-847-691-1404
>
> --
> 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/CAGg_6%2BMXQ_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMXQ_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ3_vRWvo5%2BRT5%2Bk0Dhfz2%2BKEwM6MDUM%3D6bbop%3D4tJMsA%40mail.gmail.com.
--0000000000008a32f7056de17757
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This idea raises an interesting question.<div><br></div><d=
iv>Why not make every object iterable?</div><div><br></div><div>Here's =
a quick and dirty implementation of std::begin and std::end for a std::opti=
onal</div><div><br></div><div><a href=3D"http://coliru.stacked-crooked.com/=
a/7588796d45879675">http://coliru.stacked-crooked.com/a/7588796d45879675</a=
></div><div><br></div><div>It seems to me that there is no reason that std:=
:begin(int&) could not return a std::iterator_of_one_thing<int>, =
for example.</div><div><br></div><div>Logically, it seems to me that a sing=
ular object is just a special case of an array of zero or more objects.</di=
v><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, 5 Jun 20=
18 at 09:27, Nevin Liber <<a href=3D"mailto:nevin@eviloverlord.com">nevi=
n@eviloverlord.com</a>> wrote:<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 dir=3D"ltr">On Tue, Jun 5, 2018 at 9:24 AM Corentin =
<<a href=3D"mailto:corentin.jabot@gmail.com" target=3D"_blank">corentin.=
jabot@gmail.com</a>> wrote:<br><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div>How would it =
compare to:</div><div>std::array<T,1></div></div></blockquote><div><b=
r></div><div>Array models "exactly one element", not "at mos=
t one element".</div><div>--=C2=A0<br></div></div><div dir=3D"ltr" cla=
ss=3D"gmail-m_-4537408654505722608gmail_signature"><div dir=3D"ltr"><div><d=
iv dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>> =C2=A0+1-847-691-1404</div></div></div></div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMXQ_fSxv89egbfVHOPMcFFsU79F%=
2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid=
/std-proposals/CAGg_6%2BMXQ_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%=
40mail.gmail.com</a>.<br>
</blockquote></div></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZ3_vRWvo5%2BRT5%2Bk0Dhfz2%2BKE=
wM6MDUM%3D6bbop%3D4tJMsA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Df=
ooter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3h=
Z3_vRWvo5%2BRT5%2Bk0Dhfz2%2BKEwM6MDUM%3D6bbop%3D4tJMsA%40mail.gmail.com</a>=
..<br />
--0000000000008a32f7056de17757--
.
Author: mihailnajdenov@gmail.com
Date: Tue, 5 Jun 2018 02:13:44 -0700 (PDT)
Raw View
------=_Part_22419_1285427359.1528190024425
Content-Type: multipart/alternative;
boundary="----=_Part_22420_461942306.1528190024426"
------=_Part_22420_461942306.1528190024426
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Why do you need a container (as in iterators) interface?
I also have written, I believe, two similar classes for myself and I do=20
understand the need of the other requirements, mainly to have value-like,=
=20
deep-copy heap data, but the iterators are puzzling to me.=20
On Tuesday, June 5, 2018 at 9:42:02 AM UTC+3, Nicole Mazzuca wrote:
>
> I'm sorry, I realized I didn't cover my motivation very well. The=20
> intention is
> for three things in this container -
>
> First: that it is a container. This should act like a value type, and it=
=20
> should
> have things like iterators and the like, and it should have deep copy and
> compare semantics. It's different from `std::unique_ptr` in this way.
>
> Second: It must be heap allocated - this is useful for, say, PIMPL, or=20
> recursive
> types, where `optional` is absolutely not an option.
>
> Third: It should not have any polymorphic overhead, and it should act lik=
e=20
> a
> container when it comes to allocators - this rules out something like
> `polymorphic_value`.
>
> Here's some example code using it for the pimpl idiom:
>
> https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0
>
>
> On Monday, June 4, 2018 at 11:21:55 PM UTC-7, Daniel Kr=C3=BCgler wrote:
>>
>> 2018-06-05 8:19 GMT+02:00 Nicole Mazzuca <npma...@gmail.com>:=20
>> > I've often wished for a container that can hold exactly one object -=
=20
>> > something=20
>> > like `std::unique_ptr`, but with value and container semantics. I want=
=20
>> deep=20
>> > compare, deep copy, etc. However, there isn't any container that fits=
=20
>> the=20
>> > bill=20
>> > in the current standard library. I'd like to gauge interest in having =
a=20
>> type=20
>> > like this.=20
>>
>> The term "container" confused me a bit, but other than that, you=20
>> should take a look whether std::optional meets your requirements=20
>> already.=20
>>
>> - Daniel=20
>>
>> > I've called it `box`, because that's often how these things are=20
>> referred to=20
>> > -=20
>> > Rust has `Box<T>`, Racket has `box`, Java has "Boxing". The name is=20
>> > completely=20
>> > up for bikeshedding. The interface is on my github, here:=20
>> >=20
>> > https://github.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L50=
=20
>> >=20
>> > The sample implementation of the member functions is here:=20
>> >=20
>> >=20
>> https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl.=
h=20
>> >=20
>> > I apologize for the mostly untested code, as well as any weird things=
=20
>> that=20
>> > clang-format may have done! At this point, it's just a proof of=20
>> concept.=20
>> > However, that is intended to be the "final" interface, so if there's=
=20
>> > anything in=20
>> > there you object to, or anything you'd like to see added, please speak=
=20
>> up!=20
>> >=20
>> > I'm not certain this would be good for standardization, which is why=
=20
>> I've=20
>> > placed=20
>> > it in the `ublib` namespace. I think, personally, it would be very=20
>> useful=20
>> > for=20
>> > things like recursive types, as well as whenever one wants to put=20
>> something=20
>> > behind a pointer, for whatever reason. `std::unique_ptr` is a useful=
=20
>> tool,=20
>> > but=20
>> > it's fairly poor when one wants a proper C++ container type.=20
>> >=20
>> > Some notes:=20
>> >=20
>> > First - I'm not sure whether `reverse_iterator` should be a=20
>> > `std::reverse_iterator` - it works just fine as a normal `iterator`,=
=20
>> given=20
>> > that=20
>> > there can either be zero or one elements, and a reversed range of zero=
=20
>> or=20
>> > one=20
>> > elements is the same range. I felt as though `rbegin` and the like=20
>> should be=20
>> > provided, however, as there's no reason not to have them.=20
>> >=20
>> > Second - This doesn't follow the requirements for=20
>> AllocatorAwareContainer -=20
>> > it's=20
>> > a Container, which is aware of allocators, but it uses the new=20
>> > `std::allocator_arg_t` style interface.=20
>> >=20
>> > Third - Comparison is a lexicographic comparison.=20
>> >=20
>> > And I think that's it! If you have any questions, please ask away!=20
>> >=20
>> > Thanks for your time,=20
>> >=20
>> > Nicole Mazzuca=20
>> >=20
>> > --=20
>> > You received this message because you are subscribed to the Google=20
>> Groups=20
>> > "ISO C++ Standard - Future Proposals" group.=20
>> > To unsubscribe from this group and stop receiving emails from it, send=
=20
>> an=20
>> > email to std-proposal...@isocpp.org.=20
>> > To post to this group, send email to std-pr...@isocpp.org.=20
>> > To view this discussion on the web visit=20
>> >=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f111e16b-4a=
b0-4f98-899a-f58133223ccc%40isocpp.org.=20
>>
>>
>>
>>
>> --=20
>>
>> ________________________________=20
>> SavedURI :Show URLShow URLSavedURI :=20
>> SavedURI :Hide URLHide URLSavedURI :=20
>>
>> https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN4=
ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B=
_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D1395=
770800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.L=
Et2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-=
m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=
=3D1395770800154=20
>> ________________________________=20
>>
>
--=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/7a9fac48-76ff-4680-b12d-eabea3a9b580%40isocpp.or=
g.
------=_Part_22420_461942306.1528190024426
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Why do you need a container (as in iterators) interfa=
ce?</div><div><br></div><div>I also have written, I believe, two similar cl=
asses for myself and I do understand the need of the other requirements, ma=
inly to have value-like, deep-copy heap data, but the iterators are puzzlin=
g to me.=C2=A0</div><div><br></div><br>On Tuesday, June 5, 2018 at 9:42:02 =
AM UTC+3, Nicole Mazzuca wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">I'm sorry, I realized I didn't cover my motivatio=
n very well. The intention is<br>for three things in this container -<br><b=
r>First: that it is a container. This should act like a value type, and it =
should<br>have things like iterators and the like, and it should have deep =
copy and<br>compare semantics. It's different from `std::unique_ptr` in=
this way.<br><br>Second: It must be heap allocated - this is useful for, s=
ay, PIMPL, or recursive<br>types, where `optional` is absolutely not an opt=
ion.<br><br>Third: It should not have any polymorphic overhead, and it shou=
ld act like a<br>container when it comes to allocators - this rules out som=
ething like<br>`polymorphic_value`.<br><br>Here's some example code usi=
ng it for the pimpl idiom:<br><br><a onmousedown=3D"this.href=3D'https:=
//www.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fubsan%2Fd71f7a13a=
069be0107be2842444c53f0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF68dXi5QO2T=
X4YZnMB8wVx6vKJ5Q';return true;" onclick=3D"this.href=3D'https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2Fubsan%2Fd71f7a13a069b=
e0107be2842444c53f0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF68dXi5QO2TX4YZ=
nMB8wVx6vKJ5Q';return true;" href=3D"https://gist.github.com/ubsan/d71f=
7a13a069be0107be2842444c53f0" target=3D"_blank" rel=3D"nofollow">https://gi=
st.github.com/ubsan/<wbr>d71f7a13a069be0107be2842444c53<wbr>f0</a><br><br><=
br>On Monday, June 4, 2018 at 11:21:55 PM UTC-7, Daniel Kr=C3=BCgler wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">2018-06-05 8:19 GMT+02:00 Nicole Ma=
zzuca <<a rel=3D"nofollow">npma...@gmail.com</a>>:
<br>> I've often wished for a container that can hold exactly one ob=
ject -
<br>> something
<br>> like `std::unique_ptr`, but with value and container semantics. I =
want deep
<br>> compare, deep copy, etc. However, there isn't any container th=
at fits the
<br>> bill
<br>> in the current standard library. I'd like to gauge interest in=
having a type
<br>> like this.
<br>
<br>The term "container" confused me a bit, but other than that, =
you
<br>should take a look whether std::optional meets your requirements
<br>already.
<br>
<br>- Daniel
<br>
<br>> I've called it `box`, because that's often how these thing=
s are referred to
<br>> -
<br>> Rust has `Box<T>`, Racket has `box`, Java has "Boxing&q=
uot;. The name is
<br>> completely
<br>> up for bikeshedding. The interface is on my github, here:
<br>>
<br>> <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3=
dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2=
Fublib%2Fbox.h%23L50\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFN5ZLBnUe7OEb2=
xMq6c1DcrOIceA';return true;" onclick=3D"this.href=3D'https://www.g=
oogle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaster=
%2Fbox%2Finclude%2Fublib%2Fbox.h%23L50\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAF=
QjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA';return true;" href=3D"https://github.=
com/ubsan/ublib/blob/master/box/include/ublib/box.h#L50" target=3D"_blank" =
rel=3D"nofollow">https://github.com/ubsan/<wbr>ublib/blob/master/box/includ=
e/<wbr>ublib/box.h#L50</a>
<br>>
<br>> The sample implementation of the member functions is here:
<br>>
<br>> <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3=
dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2=
Fublib%2F__box_impl.h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6X=
s3M5qxTXYv83Pgg';return true;" onclick=3D"this.href=3D'https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaste=
r%2Fbox%2Finclude%2Fublib%2F__box_impl.h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83Pgg';return true;" href=3D"https://githu=
b.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl.h" target=3D"_bl=
ank" rel=3D"nofollow">https://github.com/ubsan/<wbr>ublib/blob/master/box/i=
nclude/<wbr>ublib/__box_impl.h</a>
<br>>
<br>> I apologize for the mostly untested code, as well as any weird thi=
ngs that
<br>> clang-format may have done! At this point, it's just a proof o=
f concept.
<br>> However, that is intended to be the "final" interface, s=
o if there's
<br>> anything in
<br>> there you object to, or anything you'd like to see added, plea=
se speak up!
<br>>
<br>> I'm not certain this would be good for standardization, which =
is why I've
<br>> placed
<br>> it in the `ublib` namespace. I think, personally, it would be very=
useful
<br>> for
<br>> things like recursive types, as well as whenever one wants to put =
something
<br>> behind a pointer, for whatever reason. `std::unique_ptr` is a usef=
ul tool,
<br>> but
<br>> it's fairly poor when one wants a proper C++ container type.
<br>>
<br>> Some notes:
<br>>
<br>> First - I'm not sure whether `reverse_iterator` should be a
<br>> `std::reverse_iterator` - it works just fine as a normal `iterator=
`, given
<br>> that
<br>> there can either be zero or one elements, and a reversed range of =
zero or
<br>> one
<br>> elements is the same range. I felt as though `rbegin` and the like=
should be
<br>> provided, however, as there's no reason not to have them.
<br>>
<br>> Second - This doesn't follow the requirements for AllocatorAwa=
reContainer -
<br>> it's
<br>> a Container, which is aware of allocators, but it uses the new
<br>> `std::allocator_arg_t` style interface.
<br>>
<br>> Third - Comparison is a lexicographic comparison.
<br>>
<br>> And I think that's it! If you have any questions, please ask a=
way!
<br>>
<br>> Thanks for your time,
<br>>
<br>> Nicole Mazzuca
<br>>
<br>> --
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email 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.org</a>.
<br>> To view this discussion on the web visit
<br>> <a onmousedown=3D"this.href=3D'https://groups.google.com/a/iso=
cpp.org/d/msgid/std-proposals/f111e16b-4ab0-4f98-899a-f58133223ccc%40isocpp=
..org';return true;" onclick=3D"this.href=3D'https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f111e16b-4ab0-4f98-899a-f58133223ccc%=
40isocpp.org';return true;" href=3D"https://groups.google.com/a/isocpp.=
org/d/msgid/std-proposals/f111e16b-4ab0-4f98-899a-f58133223ccc%40isocpp.org=
" target=3D"_blank" rel=3D"nofollow">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/f111e16b-4ab0-4f98-<wbr>899a-f58133223ccc%=
40isocpp.org</a><wbr>.
<br>
<br>
<br>
<br>--=20
<br>
<br>______________________________<wbr>__
<br>SavedURI :Show URLShow URLSavedURI :
<br>SavedURI :Hide URLHide URLSavedURI :
<br><a onmousedown=3D"this.href=3D'https://mail.google.com/_/scs/mail-s=
tatic/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJ=
xhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRST=
ODy9wv1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154https://mail.google.com=
/_/scs/mail-static/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x=
3dOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1=
/rs\x3dAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154';retu=
rn true;" onclick=3D"this.href=3D'https://mail.google.com/_/scs/mail-st=
atic/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJx=
hnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTO=
Dy9wv1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154https://mail.google.com/=
_/scs/mail-static/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3=
dOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/=
rs\x3dAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154';retur=
n true;" href=3D"https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.m=
ain.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGe=
BBRgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA=
?random=3D1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dg=
mail.main.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29v=
VAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC=
4kuOWA?random=3D1395770800154" target=3D"_blank" rel=3D"nofollow">https://m=
ail.google.com/_/scs/<wbr>mail-static/_/js/k=3Dgmail.main.<wbr>de.LEt2fN4il=
LE.O/m=3Dm_i,t,it/<wbr>am=3DOCMOBiHj9kJxhnelj6j997_<wbr>NLil29vVAOBGeBBRgJw=
D-m_0_8B_<wbr>AD-qOEw/rt=3Dh/d=3D1/rs=3D<wbr>AItRSTODy9wv1JKZMABIG3Ak8ViC4k=
<wbr>uOWA?random=3D<wbr>1395770800154https://mail.<wbr>google.com/_/scs/mai=
l-static/_<wbr>/js/k=3Dgmail.main.de.<wbr>LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3D<=
wbr>OCMOBiHj9kJxhnelj6j997_<wbr>NLil29vVAOBGeBBRgJwD-m_0_8B_<wbr>AD-qOEw/rt=
=3Dh/d=3D1/rs=3D<wbr>AItRSTODy9wv1JKZMABIG3Ak8ViC4k<wbr>uOWA?random=3D13957=
70800154</a>
<br>______________________________<wbr>__
<br></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/7a9fac48-76ff-4680-b12d-eabea3a9b580%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7a9fac48-76ff-4680-b12d-eabea3a9b580=
%40isocpp.org</a>.<br />
------=_Part_22420_461942306.1528190024426--
------=_Part_22419_1285427359.1528190024425--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Tue, 5 Jun 2018 12:16:00 +0100
Raw View
--000000000000787584056de32ddd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, 5 Jun 2018 at 10:13, <mihailnajdenov@gmail.com> wrote:
> Why do you need a container (as in iterators) interface?
>
It might serve to make generic programming a little more generic.
example:
extern int get_int();
extern std::vector<int> get_vint();
auto i =3D get_int();
auto s1 =3D compute_sum(i) + compute_sum(get_vint());
https://godbolt.org/g/ye6aRo
>
> I also have written, I believe, two similar classes for myself and I do
> understand the need of the other requirements, mainly to have value-like,
> deep-copy heap data, but the iterators are puzzling to me.
>
>
> On Tuesday, June 5, 2018 at 9:42:02 AM UTC+3, Nicole Mazzuca wrote:
>>
>> I'm sorry, I realized I didn't cover my motivation very well. The
>> intention is
>> for three things in this container -
>>
>> First: that it is a container. This should act like a value type, and it
>> should
>> have things like iterators and the like, and it should have deep copy an=
d
>> compare semantics. It's different from `std::unique_ptr` in this way.
>>
>> Second: It must be heap allocated - this is useful for, say, PIMPL, or
>> recursive
>> types, where `optional` is absolutely not an option.
>>
>> Third: It should not have any polymorphic overhead, and it should act
>> like a
>> container when it comes to allocators - this rules out something like
>> `polymorphic_value`.
>>
>> Here's some example code using it for the pimpl idiom:
>>
>> https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0
>>
>>
>> On Monday, June 4, 2018 at 11:21:55 PM UTC-7, Daniel Kr=C3=BCgler wrote:
>>>
>>> 2018-06-05 8:19 GMT+02:00 Nicole Mazzuca <npma...@gmail.com>:
>>> > I've often wished for a container that can hold exactly one object -
>>> > something
>>> > like `std::unique_ptr`, but with value and container semantics. I wan=
t
>>> deep
>>> > compare, deep copy, etc. However, there isn't any container that fits
>>> the
>>> > bill
>>> > in the current standard library. I'd like to gauge interest in having
>>> a type
>>> > like this.
>>>
>>> The term "container" confused me a bit, but other than that, you
>>> should take a look whether std::optional meets your requirements
>>> already.
>>>
>>> - Daniel
>>>
>>> > I've called it `box`, because that's often how these things are
>>> referred to
>>> > -
>>> > Rust has `Box<T>`, Racket has `box`, Java has "Boxing". The name is
>>> > completely
>>> > up for bikeshedding. The interface is on my github, here:
>>> >
>>> > https://github.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L5=
0
>>> >
>>> > The sample implementation of the member functions is here:
>>> >
>>> >
>>> https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl=
..h
>>> >
>>> > I apologize for the mostly untested code, as well as any weird things
>>> that
>>> > clang-format may have done! At this point, it's just a proof of
>>> concept.
>>> > However, that is intended to be the "final" interface, so if there's
>>> > anything in
>>> > there you object to, or anything you'd like to see added, please spea=
k
>>> up!
>>> >
>>> > I'm not certain this would be good for standardization, which is why
>>> I've
>>> > placed
>>> > it in the `ublib` namespace. I think, personally, it would be very
>>> useful
>>> > for
>>> > things like recursive types, as well as whenever one wants to put
>>> something
>>> > behind a pointer, for whatever reason. `std::unique_ptr` is a useful
>>> tool,
>>> > but
>>> > it's fairly poor when one wants a proper C++ container type.
>>> >
>>> > Some notes:
>>> >
>>> > First - I'm not sure whether `reverse_iterator` should be a
>>> > `std::reverse_iterator` - it works just fine as a normal `iterator`,
>>> given
>>> > that
>>> > there can either be zero or one elements, and a reversed range of zer=
o
>>> or
>>> > one
>>> > elements is the same range. I felt as though `rbegin` and the like
>>> should be
>>> > provided, however, as there's no reason not to have them.
>>> >
>>> > Second - This doesn't follow the requirements for
>>> AllocatorAwareContainer -
>>> > it's
>>> > a Container, which is aware of allocators, but it uses the new
>>> > `std::allocator_arg_t` style interface.
>>> >
>>> > Third - Comparison is a lexicographic comparison.
>>> >
>>> > And I think that's it! If you have any questions, please ask away!
>>> >
>>> > Thanks for your time,
>>> >
>>> > Nicole Mazzuca
>>> >
>>> > --
>>> > 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, sen=
d
>>> 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/f111e16b-4=
ab0-4f98-899a-f58133223ccc%40isocpp.org.
>>>
>>>
>>>
>>>
>>> --
>>>
>>> ________________________________
>>> SavedURI :Show URLShow URLSavedURI :
>>> SavedURI :Hide URLHide URLSavedURI :
>>>
>>> https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN=
4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8=
B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D139=
5770800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.=
LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD=
-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=
=3D1395770800154
>>> ________________________________
>>>
>> --
> 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/7a9fac48-76f=
f-4680-b12d-eabea3a9b580%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7a9fac48-76=
ff-4680-b12d-eabea3a9b580%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er>
> .
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALvx3hZm1gAwnSWeMOO%2B78qEXavU%3D%2BTHb7XKDvFQ7=
ORxAiNo8A%40mail.gmail.com.
--000000000000787584056de32ddd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, 5 Jun 2018 at 10:13, <<a href=3D"mailto:mihailnajdenov@gmail.com">miha=
ilnajdenov@gmail.com</a>> wrote:<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 dir=3D"ltr"><div>Why do you need a container (as i=
n iterators) interface?</div></div></blockquote><div><br></div><div>It migh=
t serve to make generic programming a little more generic.</div><div><br></=
div><div>example:</div><div><br></div><div><div style=3D"color:rgb(0,0,0);b=
ackground-color:rgb(255,255,254)"><div><font face=3D"monospace, monospace">=
<span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,25=
5)">extern</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"co=
lor:rgb(0,0,255)">int</span><span style=3D"color:rgb(0,0,0)"> get_int();</s=
pan></font></div><div><font face=3D"monospace, monospace"><span style=3D"co=
lor:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,255)">extern</span>=
<span style=3D"color:rgb(0,0,0)"> std::vector<</span><span style=3D"colo=
r:rgb(0,0,255)">int</span><span style=3D"color:rgb(0,0,0)">> get_vint();=
</span></font></div><div><font face=3D"monospace, monospace"><span style=3D=
"color:rgb(0,0,255)">auto</span><span style=3D"color:rgb(0,0,0)"> i =3D get=
_int();</span></font></div><div><font face=3D"monospace, monospace"><span s=
tyle=3D"color:rgb(0,0,255)">auto</span><span style=3D"color:rgb(0,0,0)"> s1=
=3D compute_sum(i) + compute_sum(get_vint());</span></font></div></div><br=
></div><div><br></div><div><a href=3D"https://godbolt.org/g/ye6aRo">https:/=
/godbolt.org/g/ye6aRo</a><br></div><div><br></div><div>=C2=A0<br></div><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"><div dir=3D"ltr"><div><br></d=
iv><div>I also have written, I believe, two similar classes for myself and =
I do understand the need of the other requirements, mainly to have value-li=
ke, deep-copy heap data, but the iterators are puzzling to me.=C2=A0</div><=
div><br></div><br>On Tuesday, June 5, 2018 at 9:42:02 AM UTC+3, Nicole Mazz=
uca wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
">I'm sorry, I realized I didn't cover my motivation very well. The=
intention is<br>for three things in this container -<br><br>First: that it=
is a container. This should act like a value type, and it should<br>have t=
hings like iterators and the like, and it should have deep copy and<br>comp=
are semantics. It's different from `std::unique_ptr` in this way.<br><b=
r>Second: It must be heap allocated - this is useful for, say, PIMPL, or re=
cursive<br>types, where `optional` is absolutely not an option.<br><br>Thir=
d: It should not have any polymorphic overhead, and it should act like a<br=
>container when it comes to allocators - this rules out something like<br>`=
polymorphic_value`.<br><br>Here's some example code using it for the pi=
mpl idiom:<br><br><a href=3D"https://gist.github.com/ubsan/d71f7a13a069be01=
07be2842444c53f0" rel=3D"nofollow" target=3D"_blank">https://gist.github.co=
m/ubsan/d71f7a13a069be0107be2842444c53f0</a><br><br><br>On Monday, June 4, =
2018 at 11:21:55 PM UTC-7, Daniel Kr=C3=BCgler wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">2018-06-05 8:19 GMT+02:00 Nicole Mazzuca <<a=
rel=3D"nofollow">npma...@gmail.com</a>>:
<br>> I've often wished for a container that can hold exactly one ob=
ject -
<br>> something
<br>> like `std::unique_ptr`, but with value and container semantics. I =
want deep
<br>> compare, deep copy, etc. However, there isn't any container th=
at fits the
<br>> bill
<br>> in the current standard library. I'd like to gauge interest in=
having a type
<br>> like this.
<br>
<br>The term "container" confused me a bit, but other than that, =
you
<br>should take a look whether std::optional meets your requirements
<br>already.
<br>
<br>- Daniel
<br>
<br>> I've called it `box`, because that's often how these thing=
s are referred to
<br>> -
<br>> Rust has `Box<T>`, Racket has `box`, Java has "Boxing&q=
uot;. The name is
<br>> completely
<br>> up for bikeshedding. The interface is on my github, here:
<br>>
<br>> <a href=3D"https://github.com/ubsan/ublib/blob/master/box/include/=
ublib/box.h#L50" rel=3D"nofollow" target=3D"_blank">https://github.com/ubsa=
n/ublib/blob/master/box/include/ublib/box.h#L50</a>
<br>>
<br>> The sample implementation of the member functions is here:
<br>>
<br>> <a href=3D"https://github.com/ubsan/ublib/blob/master/box/include/=
ublib/__box_impl.h" rel=3D"nofollow" target=3D"_blank">https://github.com/u=
bsan/ublib/blob/master/box/include/ublib/__box_impl.h</a>
<br>>
<br>> I apologize for the mostly untested code, as well as any weird thi=
ngs that
<br>> clang-format may have done! At this point, it's just a proof o=
f concept.
<br>> However, that is intended to be the "final" interface, s=
o if there's
<br>> anything in
<br>> there you object to, or anything you'd like to see added, plea=
se speak up!
<br>>
<br>> I'm not certain this would be good for standardization, which =
is why I've
<br>> placed
<br>> it in the `ublib` namespace. I think, personally, it would be very=
useful
<br>> for
<br>> things like recursive types, as well as whenever one wants to put =
something
<br>> behind a pointer, for whatever reason. `std::unique_ptr` is a usef=
ul tool,
<br>> but
<br>> it's fairly poor when one wants a proper C++ container type.
<br>>
<br>> Some notes:
<br>>
<br>> First - I'm not sure whether `reverse_iterator` should be a
<br>> `std::reverse_iterator` - it works just fine as a normal `iterator=
`, given
<br>> that
<br>> there can either be zero or one elements, and a reversed range of =
zero or
<br>> one
<br>> elements is the same range. I felt as though `rbegin` and the like=
should be
<br>> provided, however, as there's no reason not to have them.
<br>>
<br>> Second - This doesn't follow the requirements for AllocatorAwa=
reContainer -
<br>> it's
<br>> a Container, which is aware of allocators, but it uses the new
<br>> `std::allocator_arg_t` style interface.
<br>>
<br>> Third - Comparison is a lexicographic comparison.
<br>>
<br>> And I think that's it! If you have any questions, please ask a=
way!
<br>>
<br>> Thanks for your time,
<br>>
<br>> Nicole Mazzuca
<br>>
<br>> --
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email 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.org</a>.
<br>> To view this discussion on the web visit
<br>> <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/f111e16b-4ab0-4f98-899a-f58133223ccc%40isocpp.org" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/f111e16b-4ab0-4f98-899a-f58133223ccc%40isocpp.org</a>.
<br>
<br>
<br>
<br>--=20
<br>
<br>________________________________
<br>SavedURI :Show URLShow URLSavedURI :
<br>SavedURI :Hide URLHide URLSavedURI :
<br><a href=3D"https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.mai=
n.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBB=
RgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?r=
andom=3D1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgma=
il.main.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVA=
OBGeBBRgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4k=
uOWA?random=3D1395770800154" rel=3D"nofollow" target=3D"_blank">https://mai=
l.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN4ilLE.O/m=3Dm_i=
,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt=3D=
h/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D1395770800154https=
://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN4ilLE.O/m=
=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw=
/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D139577080015=
4</a>
<br>________________________________
<br></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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7a9fac48-76ff-4680-b12d-eabea3a9b580%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7a9fac48-76ff-=
4680-b12d-eabea3a9b580%40isocpp.org</a>.<br>
</blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALvx3hZm1gAwnSWeMOO%2B78qEXavU%3D%2B=
THb7XKDvFQ7ORxAiNo8A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZm1g=
AwnSWeMOO%2B78qEXavU%3D%2BTHb7XKDvFQ7ORxAiNo8A%40mail.gmail.com</a>.<br />
--000000000000787584056de32ddd--
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Tue, 5 Jun 2018 08:24:38 -0700 (PDT)
Raw View
------=_Part_41221_1859327978.1528212278246
Content-Type: multipart/alternative;
boundary="----=_Part_41222_320990842.1528212278247"
------=_Part_41222_320990842.1528212278247
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
There's really no reason not to - it strictly makes the class more=20
powerful, and
it's sometimes useful to have iterators when doing generic code. This class=
=20
is
now a range and can be passed to algorithms that expect up to a=20
ContiguousRange.
On Tuesday, June 5, 2018 at 2:13:44 AM UTC-7, mihailn...@gmail.com wrote:
>
> Why do you need a container (as in iterators) interface?
>
> I also have written, I believe, two similar classes for myself and I do=
=20
> understand the need of the other requirements, mainly to have value-like,=
=20
> deep-copy heap data, but the iterators are puzzling to me.=20
>
>
> On Tuesday, June 5, 2018 at 9:42:02 AM UTC+3, Nicole Mazzuca wrote:
>>
>> I'm sorry, I realized I didn't cover my motivation very well. The=20
>> intention is
>> for three things in this container -
>>
>> First: that it is a container. This should act like a value type, and it=
=20
>> should
>> have things like iterators and the like, and it should have deep copy an=
d
>> compare semantics. It's different from `std::unique_ptr` in this way.
>>
>> Second: It must be heap allocated - this is useful for, say, PIMPL, or=
=20
>> recursive
>> types, where `optional` is absolutely not an option.
>>
>> Third: It should not have any polymorphic overhead, and it should act=20
>> like a
>> container when it comes to allocators - this rules out something like
>> `polymorphic_value`.
>>
>> Here's some example code using it for the pimpl idiom:
>>
>> https://gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0
>>
>>
>> On Monday, June 4, 2018 at 11:21:55 PM UTC-7, Daniel Kr=C3=BCgler wrote:
>>>
>>> 2018-06-05 8:19 GMT+02:00 Nicole Mazzuca <npma...@gmail.com>:=20
>>> > I've often wished for a container that can hold exactly one object -=
=20
>>> > something=20
>>> > like `std::unique_ptr`, but with value and container semantics. I wan=
t=20
>>> deep=20
>>> > compare, deep copy, etc. However, there isn't any container that fits=
=20
>>> the=20
>>> > bill=20
>>> > in the current standard library. I'd like to gauge interest in having=
=20
>>> a type=20
>>> > like this.=20
>>>
>>> The term "container" confused me a bit, but other than that, you=20
>>> should take a look whether std::optional meets your requirements=20
>>> already.=20
>>>
>>> - Daniel=20
>>>
>>> > I've called it `box`, because that's often how these things are=20
>>> referred to=20
>>> > -=20
>>> > Rust has `Box<T>`, Racket has `box`, Java has "Boxing". The name is=
=20
>>> > completely=20
>>> > up for bikeshedding. The interface is on my github, here:=20
>>> >=20
>>> > https://github.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L5=
0=20
>>> >=20
>>> > The sample implementation of the member functions is here:=20
>>> >=20
>>> >=20
>>> https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl=
..h=20
>>> >=20
>>> > I apologize for the mostly untested code, as well as any weird things=
=20
>>> that=20
>>> > clang-format may have done! At this point, it's just a proof of=20
>>> concept.=20
>>> > However, that is intended to be the "final" interface, so if there's=
=20
>>> > anything in=20
>>> > there you object to, or anything you'd like to see added, please spea=
k=20
>>> up!=20
>>> >=20
>>> > I'm not certain this would be good for standardization, which is why=
=20
>>> I've=20
>>> > placed=20
>>> > it in the `ublib` namespace. I think, personally, it would be very=20
>>> useful=20
>>> > for=20
>>> > things like recursive types, as well as whenever one wants to put=20
>>> something=20
>>> > behind a pointer, for whatever reason. `std::unique_ptr` is a useful=
=20
>>> tool,=20
>>> > but=20
>>> > it's fairly poor when one wants a proper C++ container type.=20
>>> >=20
>>> > Some notes:=20
>>> >=20
>>> > First - I'm not sure whether `reverse_iterator` should be a=20
>>> > `std::reverse_iterator` - it works just fine as a normal `iterator`,=
=20
>>> given=20
>>> > that=20
>>> > there can either be zero or one elements, and a reversed range of zer=
o=20
>>> or=20
>>> > one=20
>>> > elements is the same range. I felt as though `rbegin` and the like=20
>>> should be=20
>>> > provided, however, as there's no reason not to have them.=20
>>> >=20
>>> > Second - This doesn't follow the requirements for=20
>>> AllocatorAwareContainer -=20
>>> > it's=20
>>> > a Container, which is aware of allocators, but it uses the new=20
>>> > `std::allocator_arg_t` style interface.=20
>>> >=20
>>> > Third - Comparison is a lexicographic comparison.=20
>>> >=20
>>> > And I think that's it! If you have any questions, please ask away!=20
>>> >=20
>>> > Thanks for your time,=20
>>> >=20
>>> > Nicole Mazzuca=20
>>> >=20
>>> > --=20
>>> > You received this message because you are subscribed to the Google=20
>>> Groups=20
>>> > "ISO C++ Standard - Future Proposals" group.=20
>>> > To unsubscribe from this group and stop receiving emails from it, sen=
d=20
>>> an=20
>>> > email to std-proposal...@isocpp.org.=20
>>> > To post to this group, send email to std-pr...@isocpp.org.=20
>>> > To view this discussion on the web visit=20
>>> >=20
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f111e16b-4=
ab0-4f98-899a-f58133223ccc%40isocpp.org.=20
>>>
>>>
>>>
>>>
>>> --=20
>>>
>>> ________________________________=20
>>> SavedURI :Show URLShow URLSavedURI :=20
>>> SavedURI :Hide URLHide URLSavedURI :=20
>>>
>>> https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.LEt2fN=
4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD-m_0_8=
B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=3D139=
5770800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.main.de.=
LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBBRgJwD=
-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?random=
=3D1395770800154=20
>>> ________________________________=20
>>>
>>
--=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/c5fa8aed-a1ba-4449-8461-23b5d74c826b%40isocpp.or=
g.
------=_Part_41222_320990842.1528212278247
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There's really no reason not to - it strictly makes th=
e class more powerful, and<br>it's sometimes useful to have iterators w=
hen doing generic code. This class is<br>now a range and can be passed to a=
lgorithms that expect up to a ContiguousRange.<br><br><br>On Tuesday, June =
5, 2018 at 2:13:44 AM UTC-7, mihailn...@gmail.com wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Why do you need a contain=
er (as in iterators) interface?</div><div><br></div><div>I also have writte=
n, I believe, two similar classes for myself and I do understand the need o=
f the other requirements, mainly to have value-like, deep-copy heap data, b=
ut the iterators are puzzling to me.=C2=A0</div><div><br></div><br>On Tuesd=
ay, June 5, 2018 at 9:42:02 AM UTC+3, Nicole Mazzuca wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr">I'm sorry, I realized I didn&#=
39;t cover my motivation very well. The intention is<br>for three things in=
this container -<br><br>First: that it is a container. This should act lik=
e a value type, and it should<br>have things like iterators and the like, a=
nd it should have deep copy and<br>compare semantics. It's different fr=
om `std::unique_ptr` in this way.<br><br>Second: It must be heap allocated =
- this is useful for, say, PIMPL, or recursive<br>types, where `optional` i=
s absolutely not an option.<br><br>Third: It should not have any polymorphi=
c overhead, and it should act like a<br>container when it comes to allocato=
rs - this rules out something like<br>`polymorphic_value`.<br><br>Here'=
s some example code using it for the pimpl idiom:<br><br><a href=3D"https:/=
/gist.github.com/ubsan/d71f7a13a069be0107be2842444c53f0" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://www.google.com/url=
?q\x3dhttps%3A%2F%2Fgist.github.com%2Fubsan%2Fd71f7a13a069be0107be2842444c5=
3f0\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF68dXi5QO2TX4YZnMB8wVx6vKJ5Q=
9;;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x=
3dhttps%3A%2F%2Fgist.github.com%2Fubsan%2Fd71f7a13a069be0107be2842444c53f0\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF68dXi5QO2TX4YZnMB8wVx6vKJ5Q';r=
eturn true;">https://gist.github.com/ubsan/<wbr>d71f7a13a069be0107be2842444=
c53<wbr>f0</a><br><br><br>On Monday, June 4, 2018 at 11:21:55 PM UTC-7, Dan=
iel Kr=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">2018-06-05 8=
:19 GMT+02:00 Nicole Mazzuca <<a rel=3D"nofollow">npma...@gmail.com</a>&=
gt;:
<br>> I've often wished for a container that can hold exactly one ob=
ject -
<br>> something
<br>> like `std::unique_ptr`, but with value and container semantics. I =
want deep
<br>> compare, deep copy, etc. However, there isn't any container th=
at fits the
<br>> bill
<br>> in the current standard library. I'd like to gauge interest in=
having a type
<br>> like this.
<br>
<br>The term "container" confused me a bit, but other than that, =
you
<br>should take a look whether std::optional meets your requirements
<br>already.
<br>
<br>- Daniel
<br>
<br>> I've called it `box`, because that's often how these thing=
s are referred to
<br>> -
<br>> Rust has `Box<T>`, Racket has `box`, Java has "Boxing&q=
uot;. The name is
<br>> completely
<br>> up for bikeshedding. The interface is on my github, here:
<br>>
<br>> <a href=3D"https://github.com/ubsan/ublib/blob/master/box/include/=
ublib/box.h#L50" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hre=
f=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2=
Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2Fbox.h%23L50\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA';return true;" o=
nclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgi=
thub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2Fbox.h%23=
L50\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA=
9;;return true;">https://github.com/ubsan/<wbr>ublib/blob/master/box/includ=
e/<wbr>ublib/box.h#L50</a>
<br>>
<br>> The sample implementation of the member functions is here:
<br>>
<br>> <a href=3D"https://github.com/ubsan/ublib/blob/master/box/include/=
ublib/__box_impl.h" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.=
href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsa=
n%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2F__box_impl.h\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83Pgg';return true=
;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%=
2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2F__bo=
x_impl.h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83P=
gg';return true;">https://github.com/ubsan/<wbr>ublib/blob/master/box/i=
nclude/<wbr>ublib/__box_impl.h</a>
<br>>
<br>> I apologize for the mostly untested code, as well as any weird thi=
ngs that
<br>> clang-format may have done! At this point, it's just a proof o=
f concept.
<br>> However, that is intended to be the "final" interface, s=
o if there's
<br>> anything in
<br>> there you object to, or anything you'd like to see added, plea=
se speak up!
<br>>
<br>> I'm not certain this would be good for standardization, which =
is why I've
<br>> placed
<br>> it in the `ublib` namespace. I think, personally, it would be very=
useful
<br>> for
<br>> things like recursive types, as well as whenever one wants to put =
something
<br>> behind a pointer, for whatever reason. `std::unique_ptr` is a usef=
ul tool,
<br>> but
<br>> it's fairly poor when one wants a proper C++ container type.
<br>>
<br>> Some notes:
<br>>
<br>> First - I'm not sure whether `reverse_iterator` should be a
<br>> `std::reverse_iterator` - it works just fine as a normal `iterator=
`, given
<br>> that
<br>> there can either be zero or one elements, and a reversed range of =
zero or
<br>> one
<br>> elements is the same range. I felt as though `rbegin` and the like=
should be
<br>> provided, however, as there's no reason not to have them.
<br>>
<br>> Second - This doesn't follow the requirements for AllocatorAwa=
reContainer -
<br>> it's
<br>> a Container, which is aware of allocators, but it uses the new
<br>> `std::allocator_arg_t` style interface.
<br>>
<br>> Third - Comparison is a lexicographic comparison.
<br>>
<br>> And I think that's it! If you have any questions, please ask a=
way!
<br>>
<br>> Thanks for your time,
<br>>
<br>> Nicole Mazzuca
<br>>
<br>> --
<br>> You received this message because you are subscribed to the Google=
Groups
<br>> "ISO C++ Standard - Future Proposals" group.
<br>> To unsubscribe from this group and stop receiving emails from it, =
send an
<br>> email 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.org</a>.
<br>> To view this discussion on the web visit
<br>> <a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/f111e16b-4ab0-4f98-899a-f58133223ccc%40isocpp.org" rel=3D"nofollow" t=
arget=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/f111e16b-4ab0-4f98-899a-f58133223ccc%40i=
socpp.org';return true;" onclick=3D"this.href=3D'https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/f111e16b-4ab0-4f98-899a-f5813322=
3ccc%40isocpp.org';return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/f111e16b-4ab0-4f98-<wbr>899a-f58133223ccc%=
40isocpp.org</a><wbr>.
<br>
<br>
<br>
<br>--=20
<br>
<br>______________________________<wbr>__
<br>SavedURI :Show URLShow URLSavedURI :
<br>SavedURI :Hide URLHide URLSavedURI :
<br><a href=3D"https://mail.google.com/_/scs/mail-static/_/js/k=3Dgmail.mai=
n.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVAOBGeBB=
RgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4kuOWA?r=
andom=3D1395770800154https://mail.google.com/_/scs/mail-static/_/js/k=3Dgma=
il.main.de.LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3DOCMOBiHj9kJxhnelj6j997_NLil29vVA=
OBGeBBRgJwD-m_0_8B_AD-qOEw/rt=3Dh/d=3D1/rs=3DAItRSTODy9wv1JKZMABIG3Ak8ViC4k=
uOWA?random=3D1395770800154" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://mail.google.com/_/scs/mail-static/_/js/k\x3dgm=
ail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnelj6j997_NLil29=
vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9wv1JKZMABIG3Ak=
8ViC4kuOWA?random\x3d1395770800154https://mail.google.com/_/scs/mail-static=
/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnel=
j6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9w=
v1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154';return true;" onclick=
=3D"this.href=3D'https://mail.google.com/_/scs/mail-static/_/js/k\x3dgm=
ail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnelj6j997_NLil29=
vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9wv1JKZMABIG3Ak=
8ViC4kuOWA?random\x3d1395770800154https://mail.google.com/_/scs/mail-static=
/_/js/k\x3dgmail.main.de.LEt2fN4ilLE.O/m\x3dm_i,t,it/am\x3dOCMOBiHj9kJxhnel=
j6j997_NLil29vVAOBGeBBRgJwD-m_0_8B_AD-qOEw/rt\x3dh/d\x3d1/rs\x3dAItRSTODy9w=
v1JKZMABIG3Ak8ViC4kuOWA?random\x3d1395770800154';return true;">https://=
mail.google.com/_/scs/<wbr>mail-static/_/js/k=3Dgmail.main.<wbr>de.LEt2fN4i=
lLE.O/m=3Dm_i,t,it/<wbr>am=3DOCMOBiHj9kJxhnelj6j997_<wbr>NLil29vVAOBGeBBRgJ=
wD-m_0_8B_<wbr>AD-qOEw/rt=3Dh/d=3D1/rs=3D<wbr>AItRSTODy9wv1JKZMABIG3Ak8ViC4=
k<wbr>uOWA?random=3D<wbr>1395770800154https://mail.<wbr>google.com/_/scs/ma=
il-static/_<wbr>/js/k=3Dgmail.main.de.<wbr>LEt2fN4ilLE.O/m=3Dm_i,t,it/am=3D=
<wbr>OCMOBiHj9kJxhnelj6j997_<wbr>NLil29vVAOBGeBBRgJwD-m_0_8B_<wbr>AD-qOEw/r=
t=3Dh/d=3D1/rs=3D<wbr>AItRSTODy9wv1JKZMABIG3Ak8ViC4k<wbr>uOWA?random=3D1395=
770800154</a>
<br>______________________________<wbr>__
<br></blockquote></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/c5fa8aed-a1ba-4449-8461-23b5d74c826b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c5fa8aed-a1ba-4449-8461-23b5d74c826b=
%40isocpp.org</a>.<br />
------=_Part_41222_320990842.1528212278247--
------=_Part_41221_1859327978.1528212278246--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jun 2018 09:52:07 -0700 (PDT)
Raw View
------=_Part_41599_381352025.1528217527930
Content-Type: multipart/alternative;
boundary="----=_Part_41600_87526329.1528217527930"
------=_Part_41600_87526329.1528217527930
Content-Type: text/plain; charset="UTF-8"
On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazzuca wrote:
>
> There's really no reason not to -
>
That is a poor motivation for adding something to the standard. You need to
provide a reason *to do* something, not a reason not to do it.
Besides, it'd be much easier to just have a way to convert a
`unique_ptr<T>` into a zero/one-element `span<T*>`. That's much better than
creating a whole new type just for doing iteration over a single element.
That's what `span` is for, after all.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/783ad981-d572-40ea-b05f-8fc88d7fdd25%40isocpp.org.
------=_Part_41600_87526329.1528217527930
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazz=
uca 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">The=
re's really no reason not to -</div></blockquote><div><br></div><div>Th=
at is a poor motivation for adding something to the standard. You need to p=
rovide a reason <i>to do</i> something, not a reason not to do it.<br></div=
><div><br></div><div>Besides, it'd be much easier to just have a way to=
convert a `unique_ptr<T>` into a zero/one-element `span<T*>`. =
That's much better than creating a whole new type just for doing iterat=
ion over a single element. That's what `span` is for, after all.<br></d=
iv><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/783ad981-d572-40ea-b05f-8fc88d7fdd25%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/783ad981-d572-40ea-b05f-8fc88d7fdd25=
%40isocpp.org</a>.<br />
------=_Part_41600_87526329.1528217527930--
------=_Part_41599_381352025.1528217527930--
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Tue, 5 Jun 2018 10:00:52 -0700 (PDT)
Raw View
------=_Part_10995_11739235.1528218052734
Content-Type: multipart/alternative;
boundary="----=_Part_10996_149930843.1528218052735"
------=_Part_10996_149930843.1528218052735
Content-Type: text/plain; charset="UTF-8"
That was the motivation for adding iterators - there's no reason not to,
and it allows `box<T>` to be a container.
The motivation for adding `box<T>` are the other points - having a single
element container is great as an easy, value semantic, and idiomatic pimpl
idiom; as well as easy, value semantic, and idiomatic recursive types. It
also allows one to put the value on the heap for cache purposes, without
giving up value semantics.
On Tuesday, June 5, 2018 at 9:52:08 AM UTC-7, Nicol Bolas wrote:
>
> On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazzuca wrote:
>>
>> There's really no reason not to -
>>
>
> That is a poor motivation for adding something to the standard. You need
> to provide a reason *to do* something, not a reason not to do it.
>
> Besides, it'd be much easier to just have a way to convert a
> `unique_ptr<T>` into a zero/one-element `span<T*>`. That's much better than
> creating a whole new type just for doing iteration over a single element.
> That's what `span` is for, after all.
>
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2378bb67-64a3-46d9-8ee6-602d3f47cec5%40isocpp.org.
------=_Part_10996_149930843.1528218052735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>That was the motivation for adding iterators - there&=
#39;s no reason not to,</div><div>and it allows `box<T>` to be a cont=
ainer.<br></div><div><br></div><div>The motivation for adding `box<T>=
` are the other points - having a single</div><div>element container is gre=
at as an easy, value semantic, and idiomatic pimpl</div><div>idiom; as well=
as easy, value semantic, and idiomatic recursive types. It</div><div>also =
allows one to put the value on the heap for cache purposes, without</div><d=
iv>giving up value semantics.<br></div><br>On Tuesday, June 5, 2018 at 9:52=
:08 AM UTC-7, 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">On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Ma=
zzuca wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">There&=
#39;s really no reason not to -</div></blockquote><div><br></div><div>That =
is a poor motivation for adding something to the standard. You need to prov=
ide a reason <i>to do</i> something, not a reason not to do it.<br></div><d=
iv><br></div><div>Besides, it'd be much easier to just have a way to co=
nvert a `unique_ptr<T>` into a zero/one-element `span<T*>`. Tha=
t's much better than creating a whole new type just for doing iteration=
over a single element. That's what `span` is for, after all.<br></div>=
<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2378bb67-64a3-46d9-8ee6-602d3f47cec5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2378bb67-64a3-46d9-8ee6-602d3f47cec5=
%40isocpp.org</a>.<br />
------=_Part_10996_149930843.1528218052735--
------=_Part_10995_11739235.1528218052734--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jun 2018 12:21:50 -0700 (PDT)
Raw View
------=_Part_20952_1746792534.1528226510555
Content-Type: multipart/alternative;
boundary="----=_Part_20953_1999274423.1528226510555"
------=_Part_20953_1999274423.1528226510555
Content-Type: text/plain; charset="UTF-8"
On Tuesday, June 5, 2018 at 1:00:52 PM UTC-4, Nicole Mazzuca wrote:
>
> That was the motivation for adding iterators - there's no reason not to,
> and it allows `box<T>` to be a container.
>
"Because I can" is not a good reason for doing *anything*. `optional` could
have `size` and iterator functions too, but it doesn't. Because it's not a
container, nor should it be.
So why is it important that this `box` type act like a container? That's
the question.
The motivation for adding `box<T>` are the other points - having a single
> element container is great as an easy, value semantic, and idiomatic pimpl
> idiom;
>
Why does a pimpl type need to act like a container? And no, "there's no
reason not to" is not a reasonable answer.
as well as easy, value semantic, and idiomatic recursive types. It
> also allows one to put the value on the heap for cache purposes, without
> giving up value semantics.
>
--
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/ef7f5967-3303-45be-a62f-a7084b9c04c5%40isocpp.org.
------=_Part_20953_1999274423.1528226510555
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 5, 2018 at 1:00:52 PM UTC-4, Nicole Mazzu=
ca 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=
>That was the motivation for adding iterators - there's no reason not t=
o,</div><div>and it allows `box<T>` to be a container.<br></div></div=
></blockquote><div><br></div><div>"Because I can" is not a good r=
eason for doing <i>anything</i>. `optional` could have `size` and iterator =
functions too, but it doesn't. Because it's not a container, nor sh=
ould it be.</div><div><br></div><div>So why is it important that this `box`=
type act like a container? That's the question.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div>=
<div></div><div>The motivation for adding `box<T>` are the other poin=
ts - having a single</div><div>element container is great as an easy, value=
semantic, and idiomatic pimpl</div><div>idiom;</div></div></blockquote><di=
v><br></div><div>Why does a pimpl type need to act like a container? And no=
, "there's no reason not to" is not a reasonable answer.<br><=
/div><div><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>as well as easy, value semantic, and idiomatic recursive type=
s. It</div><div>also allows one to put the value on the heap for cache purp=
oses, without</div><div>giving up value semantics.</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/ef7f5967-3303-45be-a62f-a7084b9c04c5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef7f5967-3303-45be-a62f-a7084b9c04c5=
%40isocpp.org</a>.<br />
------=_Part_20953_1999274423.1528226510555--
------=_Part_20952_1746792534.1528226510555--
.
Author: mihailnajdenov@gmail.com
Date: Tue, 5 Jun 2018 12:32:55 -0700 (PDT)
Raw View
------=_Part_42526_17663914.1528227175167
Content-Type: multipart/alternative;
boundary="----=_Part_42527_2106325573.1528227175168"
------=_Part_42527_2106325573.1528227175168
Content-Type: text/plain; charset="UTF-8"
On Tuesday, June 5, 2018 at 8:00:52 PM UTC+3, Nicole Mazzuca wrote:
>
> That was the motivation for adding iterators - there's no reason not to,
> and it allows `box<T>` to be a container.
>
>
One reason against are semantics - does it model a collection or not.
In that regard, if I put a string into a box and box advertises iteration I
will expect these to hook into string's begin and end, much like operator[]
give access to the array elements, managed by a unique_ptr.
One might argue operator[] should be present always on the unique_ptr, much
like it is the case of standard pointers, but that is not the case.
> The motivation for adding `box<T>` are the other points - having a single
> element container is great as an easy, value semantic, and idiomatic pimpl
> idiom; as well as easy, value semantic, and idiomatic recursive types. It
> also allows one to put the value on the heap for cache purposes, without
> giving up value semantics.
>
You mention polymorphic_value. I believe an implementation can made to have
zero overhead for non-polymorphic types.
>
> On Tuesday, June 5, 2018 at 9:52:08 AM UTC-7, Nicol Bolas wrote:
>>
>> On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazzuca wrote:
>>>
>>> There's really no reason not to -
>>>
>>
>> That is a poor motivation for adding something to the standard. You need
>> to provide a reason *to do* something, not a reason not to do it.
>>
>> Besides, it'd be much easier to just have a way to convert a
>> `unique_ptr<T>` into a zero/one-element `span<T*>`. That's much better than
>> creating a whole new type just for doing iteration over a single element.
>> That's what `span` is for, after all.
>>
>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/07a5ff83-d61a-41c4-aee0-6006d9887007%40isocpp.org.
------=_Part_42527_2106325573.1528227175168
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, June 5, 2018 at 8:00:52 PM UTC+3, Nico=
le Mazzuca 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"><div>That was the motivation for adding iterators - there's no reas=
on not to,</div><div>and it allows `box<T>` to be a container.<br></d=
iv><div><br></div></div></blockquote><div><br></div><div><div style=3D"back=
ground-color: transparent; border-bottom-color: rgb(34, 34, 34); border-bot=
tom-style: none; border-bottom-width: 0px; border-image-outset: 0; border-i=
mage-repeat: stretch; border-image-slice: 100%; border-image-source: none; =
border-image-width: 1; border-left-color: rgb(34, 34, 34); border-left-styl=
e: none; border-left-width: 0px; border-right-color: rgb(34, 34, 34); borde=
r-right-style: none; border-right-width: 0px; border-top-color: rgb(34, 34,=
34); border-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34)=
; font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans=
-serif; font-size: 13px; font-style: normal; font-variant: normal; font-wei=
ght: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; mar=
gin-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-l=
eft: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-deco=
ration: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-w=
idth: 0px; white-space: normal; word-spacing: 0px;"><br style=3D"background=
-attachment: scroll; background-clip: border-box; background-color: transpa=
rent; background-image: none; background-origin: padding-box; background-po=
sition-x: 0%; background-position-y: 0%; background-repeat: repeat; backgro=
und-size: auto; border-bottom-color: rgb(34, 34, 34); border-bottom-style: =
none; border-bottom-width: 0px; border-image-outset: 0; border-image-repeat=
: stretch; border-image-slice: 100%; border-image-source: none; border-imag=
e-width: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; bo=
rder-left-width: 0px; border-right-color: rgb(34, 34, 34); border-right-sty=
le: none; border-right-width: 0px; border-top-color: rgb(34, 34, 34); borde=
r-top-style: none; border-top-width: 0px; color: rgb(34, 34, 34); font-fami=
ly: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; fon=
t-size: 13px; height: auto; margin-bottom: 0px; margin-left: 0px; margin-ri=
ght: 0px; margin-top: 0px; min-width: 0px; overflow: visible; overflow-x: v=
isible; overflow-y: visible; padding-bottom: 0px; padding-left: 0px; paddin=
g-right: 0px; padding-top: 0px;"></div><div style=3D"background-color: tran=
sparent; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; b=
order-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stret=
ch; border-image-slice: 100%; border-image-source: none; border-image-width=
: 1; border-left-color: rgb(34, 34, 34); border-left-style: none; border-le=
ft-width: 0px; border-right-color: rgb(34, 34, 34); border-right-style: non=
e; border-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-s=
tyle: none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &am=
p;quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size:=
13px; font-style: normal; font-variant: normal; font-weight: 400; letter-s=
pacing: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; ma=
rgin-top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-=
right: 0px; padding-top: 0px; text-align: left; text-decoration: none; text=
-indent: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-s=
pace: normal; word-spacing: 0px;">One reason against are semantics - does i=
t model a collection or not.</div><div style=3D"background-color: transpare=
nt; border-bottom-color: rgb(34, 34, 34); border-bottom-style: none; border=
-bottom-width: 0px; border-image-outset: 0; border-image-repeat: stretch; b=
order-image-slice: 100%; border-image-source: none; border-image-width: 1; =
border-left-color: rgb(34, 34, 34); border-left-style: none; border-left-wi=
dth: 0px; border-right-color: rgb(34, 34, 34); border-right-style: none; bo=
rder-right-width: 0px; border-top-color: rgb(34, 34, 34); border-top-style:=
none; border-top-width: 0px; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px=
; font-style: normal; font-variant: normal; font-weight: 400; letter-spacin=
g: normal; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-=
top: 0px; orphans: 2; padding-bottom: 0px; padding-left: 0px; padding-right=
: 0px; padding-top: 0px; text-align: left; text-decoration: none; text-inde=
nt: 0px; text-transform: none; -webkit-text-stroke-width: 0px; white-space:=
normal; word-spacing: 0px;"><br style=3D"background-attachment: scroll; ba=
ckground-clip: border-box; background-color: transparent; background-image:=
none; background-origin: padding-box; background-position-x: 0%; backgroun=
d-position-y: 0%; background-repeat: repeat; background-size: auto; border-=
bottom-color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-wid=
th: 0px; border-image-outset: 0; border-image-repeat: stretch; border-image=
-slice: 100%; border-image-source: none; border-image-width: 1; border-left=
-color: rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; b=
order-right-color: rgb(34, 34, 34); border-right-style: none; border-right-=
width: 0px; border-top-color: rgb(34, 34, 34); border-top-style: none; bord=
er-top-width: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&=
;quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; height: a=
uto; margin-bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0=
px; min-width: 0px; overflow: visible; overflow-x: visible; overflow-y: vis=
ible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-t=
op: 0px;"></div><div style=3D"background-color: transparent; border-bottom-=
color: rgb(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px=
; border-image-outset: 0; border-image-repeat: stretch; border-image-slice:=
100%; border-image-source: none; border-image-width: 1; border-left-color:=
rgb(34, 34, 34); border-left-style: none; border-left-width: 0px; border-r=
ight-color: rgb(34, 34, 34); border-right-style: none; border-right-width: =
0px; border-top-color: rgb(34, 34, 34); border-top-style: none; border-top-=
width: 0px; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,=
&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: norm=
al; font-variant: normal; font-weight: 400; letter-spacing: normal; margin-=
bottom: 0px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans:=
2; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top=
: 0px; text-align: left; text-decoration: none; text-indent: 0px; text-tran=
sform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-spac=
ing: 0px;">In that regard, if I put a string into a box and box advertises =
iteration I will expect these to hook into string's begin and end, much=
like operator[] give access to the array elements, managed by a unique_ptr=
..</div><div style=3D"background-color: transparent; border-bottom-color: rg=
b(34, 34, 34); border-bottom-style: none; border-bottom-width: 0px; border-=
image-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; bo=
rder-image-source: none; border-image-width: 1; border-left-color: rgb(34, =
34, 34); border-left-style: none; border-left-width: 0px; border-right-colo=
r: rgb(34, 34, 34); border-right-style: none; border-right-width: 0px; bord=
er-top-color: rgb(34, 34, 34); border-top-style: none; border-top-width: 0p=
x; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot=
;Helvetica&quot;,sans-serif; font-size: 13px; font-style: normal; font-=
variant: normal; font-weight: 400; letter-spacing: normal; margin-bottom: 0=
px; margin-left: 0px; margin-right: 0px; margin-top: 0px; orphans: 2; paddi=
ng-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; te=
xt-align: left; text-decoration: none; text-indent: 0px; text-transform: no=
ne; -webkit-text-stroke-width: 0px; white-space: normal; word-spacing: 0px;=
">One might argue operator[] should be present always on the unique_ptr, mu=
ch like it is the case of standard pointers, but that is not the case. =C2=
=A0 =C2=A0</div><b></b><i></i><u></u><sub></sub><sup></sup><strike></strike=
><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div></div><div>The motivation for adding `box<T>` are=
the other points - having a single</div><div>element container is great as=
an easy, value semantic, and idiomatic pimpl</div><div>idiom; as well as e=
asy, value semantic, and idiomatic recursive types. It</div><div>also allow=
s one to put the value on the heap for cache purposes, without</div><div>gi=
ving up value semantics.<br></div></div></blockquote><div><br></div><div>Yo=
u mention polymorphic_value. I believe an implementation can made to have z=
ero overhead for non-polymorphic types.<br></div><div><br></div><div>=C2=A0=
</div><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"><div></=
div><br>On Tuesday, June 5, 2018 at 9:52:08 AM UTC-7, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Tuesday, June 5, 2=
018 at 11:24:38 AM UTC-4, Nicole Mazzuca 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">There's really no reason not to -</div></b=
lockquote><div><br></div><div>That is a poor motivation for adding somethin=
g to the standard. You need to provide a reason <i>to do</i> something, not=
a reason not to do it.<br></div><div><br></div><div>Besides, it'd be m=
uch easier to just have a way to convert a `unique_ptr<T>` into a zer=
o/one-element `span<T*>`. That's much better than creating a whol=
e new type just for doing iteration over a single element. That's what =
`span` is for, after all.<br></div><br></div></blockquote></div></blockquot=
e></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/07a5ff83-d61a-41c4-aee0-6006d9887007%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/07a5ff83-d61a-41c4-aee0-6006d9887007=
%40isocpp.org</a>.<br />
------=_Part_42527_2106325573.1528227175168--
------=_Part_42526_17663914.1528227175167--
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Tue, 5 Jun 2018 12:50:53 -0700 (PDT)
Raw View
------=_Part_34545_1029908761.1528228253110
Content-Type: multipart/alternative;
boundary="----=_Part_34546_1675085638.1528228253110"
------=_Part_34546_1675085638.1528228253110
Content-Type: text/plain; charset="UTF-8"
Yes, it models a collection. `box<T>` does _not_ model a `T` -
would you expect `vector<string>` to hook into `string`'s
iteration functions? `unique_ptr` is not a collection - this is
explicitly intended to be used as an EoP collection of either
zero or one elements.
_This is not a special `unique_ptr` or `optional`_. It is a container
which holds either zero or one elements. It is useful because
C++ programmers expect value semantics. Asking why `box`
should have container semantics is like asking why `vector`
should have container semantics - because container semantics
are useful in generic, and non-generic, code. Especially
with the ranges TS coming Soon (tm).
On Tuesday, June 5, 2018 at 12:32:55 PM UTC-7, mihailn...@gmail.com wrote:
>
>
>
> On Tuesday, June 5, 2018 at 8:00:52 PM UTC+3, Nicole Mazzuca wrote:
>>
>> That was the motivation for adding iterators - there's no reason not to,
>> and it allows `box<T>` to be a container.
>>
>>
>
> One reason against are semantics - does it model a collection or not.
>
> In that regard, if I put a string into a box and box advertises iteration
> I will expect these to hook into string's begin and end, much like
> operator[] give access to the array elements, managed by a unique_ptr.
> One might argue operator[] should be present always on the unique_ptr,
> much like it is the case of standard pointers, but that is not the case.
>
>
>
>> The motivation for adding `box<T>` are the other points - having a single
>> element container is great as an easy, value semantic, and idiomatic pimpl
>> idiom; as well as easy, value semantic, and idiomatic recursive types. It
>> also allows one to put the value on the heap for cache purposes, without
>> giving up value semantics.
>>
>
> You mention polymorphic_value. I believe an implementation can made to
> have zero overhead for non-polymorphic types.
>
>
>
>>
>> On Tuesday, June 5, 2018 at 9:52:08 AM UTC-7, Nicol Bolas wrote:
>>>
>>> On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazzuca wrote:
>>>>
>>>> There's really no reason not to -
>>>>
>>>
>>> That is a poor motivation for adding something to the standard. You need
>>> to provide a reason *to do* something, not a reason not to do it.
>>>
>>> Besides, it'd be much easier to just have a way to convert a
>>> `unique_ptr<T>` into a zero/one-element `span<T*>`. That's much better than
>>> creating a whole new type just for doing iteration over a single element.
>>> That's what `span` is for, after all.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c4cc67d5-89d9-4fa1-8b24-8057511883ce%40isocpp.org.
------=_Part_34546_1675085638.1528228253110
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Yes, it models a collection. `box<T>` does _not=
_ model a `T` -</div><div>would you expect `vector<string>` to hook i=
nto `string`'s</div><div>iteration functions? `unique_ptr` is not a col=
lection - this is</div><div>explicitly intended to be used as an EoP collec=
tion of either</div><div>zero or one elements.</div><div><br></div><div>_Th=
is is not a special `unique_ptr` or `optional`_. It is a container</div><di=
v>which holds either zero or one elements. It is useful because</div><div>C=
++ programmers expect value semantics. Asking why `box`</div><div>should ha=
ve container semantics is like asking why `vector`</div><div>should have co=
ntainer semantics - because container semantics</div><div>are useful in gen=
eric, and non-generic, code. Especially</div><div>with the ranges TS coming=
Soon (tm).<br></div><div><br></div>On Tuesday, June 5, 2018 at 12:32:55 PM=
UTC-7, mihailn...@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 dir=3D"ltr"><br><br>On Tuesday, June 5, 2018 at 8:00:52 PM UTC+3=
, Nicole Mazzuca 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>That was the motivation for adding iterators - there's no rea=
son not to,</div><div>and it allows `box<T>` to be a container.<br></=
div><div><br></div></div></blockquote><div><br></div><div><div><br></div><d=
iv>One reason against are semantics - does it model a collection or not.</d=
iv><div><br></div><div>In that regard, if I put a string into a box and box=
advertises iteration I will expect these to hook into string's begin a=
nd end, much like operator[] give access to the array elements, managed by =
a unique_ptr.</div><div>One might argue operator[] should be present always=
on the unique_ptr, much like it is the case of standard pointers, but that=
is not the case. =C2=A0 =C2=A0</div><b></b><i></i><u></u><sub></sub><sup><=
/sup><strike></strike><br></div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div></div><div>The motivation for adding `b=
ox<T>` are the other points - having a single</div><div>element conta=
iner is great as an easy, value semantic, and idiomatic pimpl</div><div>idi=
om; as well as easy, value semantic, and idiomatic recursive types. It</div=
><div>also allows one to put the value on the heap for cache purposes, with=
out</div><div>giving up value semantics.<br></div></div></blockquote><div><=
br></div><div>You mention polymorphic_value. I believe an implementation ca=
n made to have zero overhead for non-polymorphic types.<br></div><div><br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div></div><br>On Tuesday, June 5, 2018 at 9:52:08 AM UTC-7, Nicol Bola=
s 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">On Tuesday=
, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazzuca wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">There's really no reason not to=
-</div></blockquote><div><br></div><div>That is a poor motivation for addi=
ng something to the standard. You need to provide a reason <i>to do</i> som=
ething, not a reason not to do it.<br></div><div><br></div><div>Besides, it=
'd be much easier to just have a way to convert a `unique_ptr<T>`=
into a zero/one-element `span<T*>`. That's much better than crea=
ting a whole new type just for doing iteration over a single element. That&=
#39;s what `span` is for, after all.<br></div><br></div></blockquote></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/c4cc67d5-89d9-4fa1-8b24-8057511883ce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c4cc67d5-89d9-4fa1-8b24-8057511883ce=
%40isocpp.org</a>.<br />
------=_Part_34546_1675085638.1528228253110--
------=_Part_34545_1029908761.1528228253110--
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Tue, 5 Jun 2018 12:51:38 -0700 (PDT)
Raw View
------=_Part_39179_759664591.1528228298429
Content-Type: multipart/alternative;
boundary="----=_Part_39180_514615461.1528228298429"
------=_Part_39180_514615461.1528228298429
Content-Type: text/plain; charset="UTF-8"
Any further questions about it modeling a container will be pointed to
Elements
of Programming ;)
On Monday, June 4, 2018 at 11:19:27 PM UTC-7, Nicole Mazzuca wrote:
>
> I've often wished for a container that can hold exactly one object -
> something
> like `std::unique_ptr`, but with value and container semantics. I want deep
> compare, deep copy, etc. However, there isn't any container that fits the
> bill
> in the current standard library. I'd like to gauge interest in having a
> type
> like this.
>
> I've called it `box`, because that's often how these things are referred
> to -
> Rust has `Box<T>`, Racket has `box`, Java has "Boxing". The name is
> completely
> up for bikeshedding. The interface is on my github, here:
>
> https://github.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L50
>
> The sample implementation of the member functions is here:
>
> https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl.h
>
> I apologize for the mostly untested code, as well as any weird things that
> clang-format may have done! At this point, it's just a proof of concept.
> However, that is intended to be the "final" interface, so if there's
> anything in
> there you object to, or anything you'd like to see added, please speak up!
>
> I'm not certain this would be good for standardization, which is why I've
> placed
> it in the `ublib` namespace. I think, personally, it would be very useful
> for
> things like recursive types, as well as whenever one wants to put something
> behind a pointer, for whatever reason. `std::unique_ptr` is a useful tool,
> but
> it's fairly poor when one wants a proper C++ container type.
>
> Some notes:
>
> First - I'm not sure whether `reverse_iterator` should be a
> `std::reverse_iterator` - it works just fine as a normal `iterator`, given
> that
> there can either be zero or one elements, and a reversed range of zero or
> one
> elements is the same range. I felt as though `rbegin` and the like should
> be
> provided, however, as there's no reason not to have them.
>
> Second - This doesn't follow the requirements for AllocatorAwareContainer
> - it's
> a Container, which is aware of allocators, but it uses the new
> `std::allocator_arg_t` style interface.
>
> Third - Comparison is a lexicographic comparison.
>
> And I think that's it! If you have any questions, please ask away!
>
> Thanks for your time,
>
> Nicole Mazzuca
>
--
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/5e025426-ff3e-4f9d-8b40-7510ddf51189%40isocpp.org.
------=_Part_39180_514615461.1528228298429
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Any further questions about it modeling a container w=
ill be pointed to Elements</div><div>of Programming ;)<br></div><br>On Mond=
ay, June 4, 2018 at 11:19:27 PM UTC-7, Nicole Mazzuca wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I've often wished for a =
container that can hold exactly one object - something<br>like `std::unique=
_ptr`, but with value and container semantics. I want deep<br>compare, deep=
copy, etc. However, there isn't any container that fits the bill<br>in=
the current standard library. I'd like to gauge interest in having a t=
ype<br>like this.<br><br>I've called it `box`, because that's often=
how these things are referred to -<br>Rust has `Box<T>`, Racket has =
`box`, Java has "Boxing". The name is completely<br>up for bikesh=
edding. The interface is on my github, here:<br><br><a href=3D"https://gith=
ub.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L50" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.com/=
url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Fi=
nclude%2Fublib%2Fbox.h%23L50\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFN5ZLB=
nUe7OEb2xMq6c1DcrOIceA';return true;" onclick=3D"this.href=3D'https=
://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob%=
2Fmaster%2Fbox%2Finclude%2Fublib%2Fbox.h%23L50\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA';return true;">https://github.=
com/ubsan/<wbr>ublib/blob/master/box/include/<wbr>ublib/box.h#L50</a><br><b=
r>The sample implementation of the member functions is here:<br><br><a href=
=3D"https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl=
..h" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'http=
s://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob=
%2Fmaster%2Fbox%2Finclude%2Fublib%2F__box_impl.h\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83Pgg';return true;" onclick=3D"th=
is.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fu=
bsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2F__box_impl.h\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83Pgg';return t=
rue;">https://github.com/ubsan/<wbr>ublib/blob/master/box/include/<wbr>ubli=
b/__box_impl.h</a><br><br>I apologize for the mostly untested code, as well=
as any weird things that<br>clang-format may have done! At this point, it&=
#39;s just a proof of concept.<br>However, that is intended to be the "=
;final" interface, so if there's anything in<br>there you object t=
o, or anything you'd like to see added, please speak up!<br><br>I'm=
not certain this would be good for standardization, which is why I've =
placed<br>it in the `ublib` namespace. I think, personally, it would be ver=
y useful for<br>things like recursive types, as well as whenever one wants =
to put something<br>behind a pointer, for whatever reason. `std::unique_ptr=
` is a useful tool, but<br>it's fairly poor when one wants a proper C++=
container type.<br><br>Some notes:<br><br>First - I'm not sure whether=
`reverse_iterator` should be a<br>`std::reverse_iterator` - it works just =
fine as a normal `iterator`, given that<br>there can either be zero or one =
elements, and a reversed range of zero or one<br>elements is the same range=
.. I felt as though `rbegin` and the like should be<br>provided, however, as=
there's no reason not to have them.<br><br>Second - This doesn't f=
ollow the requirements for AllocatorAwareContainer - it's<br>a Containe=
r, which is aware of allocators, but it uses the new<br>`std::allocator_arg=
_t` style interface.<br><br>Third - Comparison is a lexicographic compariso=
n.<br><br>And I think that's it! If you have any questions, please ask =
away!<br><br>Thanks for your time,<br><br>Nicole Mazzuca<br></div></blockqu=
ote></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/5e025426-ff3e-4f9d-8b40-7510ddf51189%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5e025426-ff3e-4f9d-8b40-7510ddf51189=
%40isocpp.org</a>.<br />
------=_Part_39180_514615461.1528228298429--
------=_Part_39179_759664591.1528228298429--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jun 2018 16:10:05 -0700 (PDT)
Raw View
------=_Part_26871_1747345231.1528240205237
Content-Type: multipart/alternative;
boundary="----=_Part_26872_2063428178.1528240205237"
------=_Part_26872_2063428178.1528240205237
Content-Type: text/plain; charset="UTF-8"
On Tuesday, June 5, 2018 at 3:50:53 PM UTC-4, Nicole Mazzuca wrote:
>
> Yes, it models a collection. `box<T>` does _not_ model a `T` -
> would you expect `vector<string>` to hook into `string`'s
> iteration functions? `unique_ptr` is not a collection - this is
> explicitly intended to be used as an EoP collection of either
> zero or one elements.
>
> _This is not a special `unique_ptr` or `optional`_. It is a container
> which holds either zero or one elements. It is useful because
> C++ programmers expect value semantics. Asking why `box`
> should have container semantics is like asking why `vector`
> should have container semantics - because container semantics
> are useful in generic, and non-generic, code.
>
No, `vector` has container semantics because being a container *is its job*.
That's what it is at its core: a contiguous container. Containers of
contiguous elements are useful; ergo, `vector` exists.
What is `box` and why would people want it? You seem to have assembled a
grab-bag set of features (container, polymorphic deep copy, value
semantics, etc), without explaining why someone would need one type that
services all of those needs. Why does a container of one element needs to
have deep copy semantics, when every container of many elements doesn't
have deep copy semantics?
Especially
> with the ranges TS coming Soon (tm).
>
--
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/6db2a305-5208-4a3d-ae1b-83f9a7ef1052%40isocpp.org.
------=_Part_26872_2063428178.1528240205237
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 5, 2018 at 3:50:53 PM UTC-4, Nicole Mazzu=
ca 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=
>Yes, it models a collection. `box<T>` does _not_ model a `T` -</div>=
<div>would you expect `vector<string>` to hook into `string`'s</d=
iv><div>iteration functions? `unique_ptr` is not a collection - this is</di=
v><div>explicitly intended to be used as an EoP collection of either</div><=
div>zero or one elements.</div><div><br></div><div>_This is not a special `=
unique_ptr` or `optional`_. It is a container</div><div>which holds either =
zero or one elements. It is useful because</div><div>C++ programmers expect=
value semantics. Asking why `box`</div><div>should have container semantic=
s is like asking why `vector`</div><div>should have container semantics - b=
ecause container semantics</div><div>are useful in generic, and non-generic=
, code.</div></div></blockquote><div><br></div><div>No, `vector` has contai=
ner semantics because being a container <i>is its job</i>. That's what =
it is at its core: a contiguous container. Containers of contiguous element=
s are useful; ergo, `vector` exists.<br></div><div><br></div><div>What is `=
box` and why would people want it? You seem to have assembled a grab-bag se=
t of features (container, polymorphic deep copy, value semantics, etc), wit=
hout explaining why someone would need one type that services all of those =
needs. Why does a container of one element needs to have deep copy semantic=
s, when every container of many elements doesn't have deep copy semanti=
cs?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div> Especially</div><div>with the ranges TS coming Soon (tm).<=
/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/6db2a305-5208-4a3d-ae1b-83f9a7ef1052%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6db2a305-5208-4a3d-ae1b-83f9a7ef1052=
%40isocpp.org</a>.<br />
------=_Part_26872_2063428178.1528240205237--
------=_Part_26871_1747345231.1528240205237--
.
Author: Nicole Mazzuca <npmazzuca@gmail.com>
Date: Tue, 5 Jun 2018 17:09:41 -0700 (PDT)
Raw View
------=_Part_44097_912585183.1528243781687
Content-Type: multipart/alternative;
boundary="----=_Part_44098_1577108810.1528243781687"
------=_Part_44098_1577108810.1528243781687
Content-Type: text/plain; charset="UTF-8"
Alright, apparently I haven't made my assumptions clear.
I want value semantics because value semantics are nice, and almost
all types should be value semantic. This is the core idea of C++, I would
argue.
Having a type like `box` allows you to keep your recursive types and
pimpl code simple, and correct.
> Why does a container of one element needs to have deep copy semantics,
when every container of many elements doesn't have deep copy semantics?
This sentence doesn't make sense. Every container has deep copy
semantics. I think you've misunderstood something? I said "deep copy"
as opposed to a shallow copy, like `shared_ptr`. This means that
auto x = box(0);
auto y = x;
/*
*y == 0
*x == 0
std::addressof(*y) != std::addressof(*x)
x == y
*/
This type's job is being a container of one element, because having a
container of one element is useful for some specific idioms.
I have assembled exactly three things into a single type - container,
allocator awareness, and maximum of one element. The first two are
useful, and have proved their usefulness, over the past 20 years.
The latter, I would posit, is useful for people who want value-semantic
types which, today, would require a `unique_ptr` or `shared_ptr`,
custom equality operators, and a custom copy constructor; or, worse,
a normal pointer that they then have to write a RAII wrapper around
for themselves.
On Tuesday, June 5, 2018 at 4:10:05 PM UTC-7, Nicol Bolas wrote:
>
> On Tuesday, June 5, 2018 at 3:50:53 PM UTC-4, Nicole Mazzuca wrote:
>>
>> Yes, it models a collection. `box<T>` does _not_ model a `T` -
>> would you expect `vector<string>` to hook into `string`'s
>> iteration functions? `unique_ptr` is not a collection - this is
>> explicitly intended to be used as an EoP collection of either
>> zero or one elements.
>>
>> _This is not a special `unique_ptr` or `optional`_. It is a container
>> which holds either zero or one elements. It is useful because
>> C++ programmers expect value semantics. Asking why `box`
>> should have container semantics is like asking why `vector`
>> should have container semantics - because container semantics
>> are useful in generic, and non-generic, code.
>>
>
> No, `vector` has container semantics because being a container *is its
> job*. That's what it is at its core: a contiguous container. Containers
> of contiguous elements are useful; ergo, `vector` exists.
>
> What is `box` and why would people want it? You seem to have assembled a
> grab-bag set of features (container, polymorphic deep copy, value
> semantics, etc), without explaining why someone would need one type that
> services all of those needs. Why does a container of one element needs to
> have deep copy semantics, when every container of many elements doesn't
> have deep copy semantics?
>
> Especially
>> with the ranges TS coming Soon (tm).
>>
>
--
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/00d880df-9c01-4571-8515-edd516a453ce%40isocpp.org.
------=_Part_44098_1577108810.1528243781687
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Alright, apparently I haven't made my assumptions=
clear.</div><div><br></div><div>I want value semantics because value seman=
tics are nice, and almost</div><div>all types should be value semantic. Thi=
s is the core idea of C++, I would</div><div>argue.<br></div><div><br></div=
><div>Having a type like `box` allows you to keep your recursive types and<=
/div><div>pimpl code simple, and correct.</div><div><br></div><div> > Wh=
y does a container of one element needs to have deep copy semantics,=20
when every container of many elements doesn't have deep copy semantics?=
</div><div><br></div><div>This sentence doesn't make sense. Every conta=
iner has deep copy</div><div>semantics. I think you've misunderstood so=
mething? I said "deep copy"</div><div>as opposed to a shallow cop=
y, like `shared_ptr`. This means that</div><div><br></div><div>=C2=A0=C2=A0=
=C2=A0 auto x =3D box(0);</div><div>=C2=A0=C2=A0=C2=A0 auto y =3D x;</div><=
div>=C2=A0=C2=A0=C2=A0 /*</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *y =3D=
=3D 0</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *x =3D=3D 0</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 std::addressof(*y) !=3D std::addressof(*x)</div><d=
iv>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x =3D=3D y<br></div><div>=C2=A0=C2=A0=C2=
=A0 */<br></div><div><br></div><div>This type's job is being a containe=
r of one element, because having a</div><div>container of one element is us=
eful for some specific idioms.</div><div><br></div><div>I have assembled ex=
actly three things into a single type - container,</div><div>allocator awar=
eness, and maximum of one element. The first two are</div><div>useful, and =
have proved their usefulness, over the past 20 years.</div><div>The latter,=
I would posit, is useful for people who want value-semantic</div><div>type=
s which, today, would require a `unique_ptr` or `shared_ptr`,</div><div>cus=
tom equality operators, and a custom copy constructor; or, worse,</div><div=
>a normal pointer that they then have to write a RAII wrapper around</div><=
div>for themselves.</div><div><br></div>On Tuesday, June 5, 2018 at 4:10:05=
PM UTC-7, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">On Tuesday, June 5, 2018 at 3:50:53 PM UTC-4, Nicole Mazzuc=
a 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"><div>Yes, =
it models a collection. `box<T>` does _not_ model a `T` -</div><div>w=
ould you expect `vector<string>` to hook into `string`'s</div><di=
v>iteration functions? `unique_ptr` is not a collection - this is</div><div=
>explicitly intended to be used as an EoP collection of either</div><div>ze=
ro or one elements.</div><div><br></div><div>_This is not a special `unique=
_ptr` or `optional`_. It is a container</div><div>which holds either zero o=
r one elements. It is useful because</div><div>C++ programmers expect value=
semantics. Asking why `box`</div><div>should have container semantics is l=
ike asking why `vector`</div><div>should have container semantics - because=
container semantics</div><div>are useful in generic, and non-generic, code=
..</div></div></blockquote><div><br></div><div>No, `vector` has container se=
mantics because being a container <i>is its job</i>. That's what it is =
at its core: a contiguous container. Containers of contiguous elements are =
useful; ergo, `vector` exists.<br></div><div><br></div><div>What is `box` a=
nd why would people want it? You seem to have assembled a grab-bag set of f=
eatures (container, polymorphic deep copy, value semantics, etc), without e=
xplaining why someone would need one type that services all of those needs.=
Why does a container of one element needs to have deep copy semantics, whe=
n every container of many elements doesn't have deep copy semantics?</d=
iv><div><br></div><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"ltr">=
<div> Especially</div><div>with the ranges TS coming Soon (tm).</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/00d880df-9c01-4571-8515-edd516a453ce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00d880df-9c01-4571-8515-edd516a453ce=
%40isocpp.org</a>.<br />
------=_Part_44098_1577108810.1528243781687--
------=_Part_44097_912585183.1528243781687--
.
Author: Justin Bassett <jbassett271@gmail.com>
Date: Tue, 5 Jun 2018 18:54:57 -0700
Raw View
--000000000000f947a0056def7430
Content-Type: text/plain; charset="UTF-8"
I like this idea. It makes sense to me to have a simple type which models
these concepts.
As an analogy, consider the identity function. If you think of it just like
a regular C style function, it's useless. It is defined to "do nothing."
However, it becomes incredibly useful once you start using higher level
functions.
Similarly, having `box` meet the concept of a container is useful for
generic programming. I can't say that I've personally found a use for it,
but to me it makes just as much sense as the identity function.
On Tue, Jun 5, 2018, 5:09 PM Nicole Mazzuca <npmazzuca@gmail.com> wrote:
> Alright, apparently I haven't made my assumptions clear.
>
> I want value semantics because value semantics are nice, and almost
> all types should be value semantic. This is the core idea of C++, I would
> argue.
>
> Having a type like `box` allows you to keep your recursive types and
> pimpl code simple, and correct.
>
> > Why does a container of one element needs to have deep copy semantics,
> when every container of many elements doesn't have deep copy semantics?
>
> This sentence doesn't make sense. Every container has deep copy
> semantics. I think you've misunderstood something? I said "deep copy"
> as opposed to a shallow copy, like `shared_ptr`. This means that
>
> auto x = box(0);
> auto y = x;
> /*
> *y == 0
> *x == 0
> std::addressof(*y) != std::addressof(*x)
> x == y
> */
>
> This type's job is being a container of one element, because having a
> container of one element is useful for some specific idioms.
>
> I have assembled exactly three things into a single type - container,
> allocator awareness, and maximum of one element. The first two are
> useful, and have proved their usefulness, over the past 20 years.
> The latter, I would posit, is useful for people who want value-semantic
> types which, today, would require a `unique_ptr` or `shared_ptr`,
> custom equality operators, and a custom copy constructor; or, worse,
> a normal pointer that they then have to write a RAII wrapper around
> for themselves.
>
> On Tuesday, June 5, 2018 at 4:10:05 PM UTC-7, Nicol Bolas wrote:
>>
>> On Tuesday, June 5, 2018 at 3:50:53 PM UTC-4, Nicole Mazzuca wrote:
>>>
>>> Yes, it models a collection. `box<T>` does _not_ model a `T` -
>>> would you expect `vector<string>` to hook into `string`'s
>>> iteration functions? `unique_ptr` is not a collection - this is
>>> explicitly intended to be used as an EoP collection of either
>>> zero or one elements.
>>>
>>> _This is not a special `unique_ptr` or `optional`_. It is a container
>>> which holds either zero or one elements. It is useful because
>>> C++ programmers expect value semantics. Asking why `box`
>>> should have container semantics is like asking why `vector`
>>> should have container semantics - because container semantics
>>> are useful in generic, and non-generic, code.
>>>
>>
>> No, `vector` has container semantics because being a container *is its
>> job*. That's what it is at its core: a contiguous container. Containers
>> of contiguous elements are useful; ergo, `vector` exists.
>>
>> What is `box` and why would people want it? You seem to have assembled a
>> grab-bag set of features (container, polymorphic deep copy, value
>> semantics, etc), without explaining why someone would need one type that
>> services all of those needs. Why does a container of one element needs to
>> have deep copy semantics, when every container of many elements doesn't
>> have deep copy semantics?
>>
>> Especially
>>> with the ranges TS coming Soon (tm).
>>>
>> --
> 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/00d880df-9c01-4571-8515-edd516a453ce%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00d880df-9c01-4571-8515-edd516a453ce%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5do4kcNnQBnvwcKwWztWp8FMZHRvn-E%3DtsV0P%3DhnGc73A%40mail.gmail.com.
--000000000000f947a0056def7430
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">I like this idea. It makes sense to me to have a simple t=
ype which models these concepts.<div dir=3D"auto"><br></div><div dir=3D"aut=
o">As an analogy, consider the identity function. If you think of it just l=
ike a regular C style function, it's useless. It is defined to "do=
nothing." However, it becomes incredibly useful once you start using =
higher level functions.</div><div dir=3D"auto"><br></div><div dir=3D"auto">=
Similarly, having `box` meet the concept of a container is useful for gener=
ic programming. I can't say that I've personally found a use for it=
, but to me it makes just as much sense as the identity function.</div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jun 5, 2018, 5:09=
PM Nicole Mazzuca <<a href=3D"mailto:npmazzuca@gmail.com">npmazzuca@gma=
il.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>Alright, apparently I haven't made my assumptions clear.</div>=
<div><br></div><div>I want value semantics because value semantics are nice=
, and almost</div><div>all types should be value semantic. This is the core=
idea of C++, I would</div><div>argue.<br></div><div><br></div><div>Having =
a type like `box` allows you to keep your recursive types and</div><div>pim=
pl code simple, and correct.</div><div><br></div><div> > Why does a cont=
ainer of one element needs to have deep copy semantics,=20
when every container of many elements doesn't have deep copy semantics?=
</div><div><br></div><div>This sentence doesn't make sense. Every conta=
iner has deep copy</div><div>semantics. I think you've misunderstood so=
mething? I said "deep copy"</div><div>as opposed to a shallow cop=
y, like `shared_ptr`. This means that</div><div><br></div><div>=C2=A0=C2=A0=
=C2=A0 auto x =3D box(0);</div><div>=C2=A0=C2=A0=C2=A0 auto y =3D x;</div><=
div>=C2=A0=C2=A0=C2=A0 /*</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *y =3D=
=3D 0</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *x =3D=3D 0</div><div>=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 std::addressof(*y) !=3D std::addressof(*x)</div><d=
iv>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 x =3D=3D y<br></div><div>=C2=A0=C2=A0=C2=
=A0 */<br></div><div><br></div><div>This type's job is being a containe=
r of one element, because having a</div><div>container of one element is us=
eful for some specific idioms.</div><div><br></div><div>I have assembled ex=
actly three things into a single type - container,</div><div>allocator awar=
eness, and maximum of one element. The first two are</div><div>useful, and =
have proved their usefulness, over the past 20 years.</div><div>The latter,=
I would posit, is useful for people who want value-semantic</div><div>type=
s which, today, would require a `unique_ptr` or `shared_ptr`,</div><div>cus=
tom equality operators, and a custom copy constructor; or, worse,</div><div=
>a normal pointer that they then have to write a RAII wrapper around</div><=
div>for themselves.</div><div><br></div>On Tuesday, June 5, 2018 at 4:10:05=
PM UTC-7, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">On Tuesday, June 5, 2018 at 3:50:53 PM UTC-4, Nicole Mazzuca wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Yes, it mo=
dels a collection. `box<T>` does _not_ model a `T` -</div><div>would =
you expect `vector<string>` to hook into `string`'s</div><div>ite=
ration functions? `unique_ptr` is not a collection - this is</div><div>expl=
icitly intended to be used as an EoP collection of either</div><div>zero or=
one elements.</div><div><br></div><div>_This is not a special `unique_ptr`=
or `optional`_. It is a container</div><div>which holds either zero or one=
elements. It is useful because</div><div>C++ programmers expect value sema=
ntics. Asking why `box`</div><div>should have container semantics is like a=
sking why `vector`</div><div>should have container semantics - because cont=
ainer semantics</div><div>are useful in generic, and non-generic, code.</di=
v></div></blockquote><div><br></div><div>No, `vector` has container semanti=
cs because being a container <i>is its job</i>. That's what it is at it=
s core: a contiguous container. Containers of contiguous elements are usefu=
l; ergo, `vector` exists.<br></div><div><br></div><div>What is `box` and wh=
y would people want it? You seem to have assembled a grab-bag set of featur=
es (container, polymorphic deep copy, value semantics, etc), without explai=
ning why someone would need one type that services all of those needs. Why =
does a container of one element needs to have deep copy semantics, when eve=
ry container of many elements doesn't have deep copy semantics?</div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
Especially</div><div>with the ranges TS coming Soon (tm).</div></div></blo=
ckquote></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" target=3D"_=
blank" rel=3D"noreferrer">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank" rel=3D"noreferrer">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/00d880df-9c01-4571-8515-edd516a453ce%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank" =
rel=3D"noreferrer">https://groups.google.com/a/isocpp.org/d/msgid/std-propo=
sals/00d880df-9c01-4571-8515-edd516a453ce%40isocpp.org</a>.<br>
</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/CAPuuy5do4kcNnQBnvwcKwWztWp8FMZHRvn-E=
%3DtsV0P%3DhnGc73A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPuuy5do4kcN=
nQBnvwcKwWztWp8FMZHRvn-E%3DtsV0P%3DhnGc73A%40mail.gmail.com</a>.<br />
--000000000000f947a0056def7430--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 5 Jun 2018 19:14:29 -0700 (PDT)
Raw View
------=_Part_12691_166202413.1528251269725
Content-Type: multipart/alternative;
boundary="----=_Part_12692_947268232.1528251269725"
------=_Part_12692_947268232.1528251269725
Content-Type: text/plain; charset="UTF-8"
On Tuesday, June 5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzuca wrote:
>
> Alright, apparently I haven't made my assumptions clear.
>
> I want value semantics because value semantics are nice, and almost
> all types should be value semantic. This is the core idea of C++, I would
> argue.
>
> Having a type like `box` allows you to keep your recursive types and
> pimpl code simple, and correct.
>
OK, but what does it have to do with being a container? Why does a simple
`value_ptr` type need the interface of a container? Can you provide one
*genuine*, real-world example where this is useful? An example that a
`span<T, 1>` couldn't resolve adequately?
Fat interfaces are bad, even when you're not using them as base classes. If
you want to merge these two interfaces, you need to explain *why*.
> Why does a container of one element needs to have deep copy semantics,
> when every container of many elements doesn't have deep copy semantics?
>
> This sentence doesn't make sense. Every container has deep copy
> semantics. I think you've misunderstood something? I said "deep copy"
> as opposed to a shallow copy, like `shared_ptr`.
>
Apparently, I misunderstood. Generally speaking, when people say "deep
copy" around the words "polymorphism", what they mean is "box<T> can store
a pointer to a type U derived from T, and if I copy that box<T>, then it
will create a new U instance in the new box<T> via <insert magic here>."
But you don't seem to be wanting that.
So you're just talking about "value semantics". `unique_ptr` and
`shared_ptr` don't have value semantics; they have reference semantics.
Containers have value semantics.
--
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/1927647f-a6aa-4136-bd17-1bd69243a197%40isocpp.org.
------=_Part_12692_947268232.1528251269725
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, June 5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzu=
ca 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=
>Alright, apparently I haven't made my assumptions clear.</div><div><br=
></div><div>I want value semantics because value semantics are nice, and al=
most</div><div>all types should be value semantic. This is the core idea of=
C++, I would</div><div>argue.<br></div><div><br></div><div>Having a type l=
ike `box` allows you to keep your recursive types and</div><div>pimpl code =
simple, and correct.</div></div></blockquote><div><br></div><div>OK, but wh=
at does it have to do with being a container? Why does a simple `value_ptr`=
type need the interface of a container? Can you provide one <i>genuine</i>=
, real-world example where this is useful? An example that a `span<T, 1&=
gt;` couldn't resolve adequately?<br></div><div><br></div><div>Fat inte=
rfaces are bad, even when you're not using them as base classes. If you=
want to merge these two interfaces, you need to explain <i>why</i>.<br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div></div><div> > Why does a container of one element needs to hav=
e deep copy semantics,=20
when every container of many elements doesn't have deep copy semantics?=
</div><div><br></div><div>This sentence doesn't make sense. Every conta=
iner has deep copy</div><div>semantics. I think you've misunderstood so=
mething? I said "deep copy"</div><div>as opposed to a shallow cop=
y, like `shared_ptr`.</div></div></blockquote><div><br></div><div>Apparentl=
y, I misunderstood. Generally speaking, when people say "deep copy&quo=
t; around the words "polymorphism", what they mean is "box&l=
t;T> can store a pointer to a type U derived from T, and if I copy that =
box<T>, then it will create a new U instance in the new box<T> =
via <insert magic here>." But you don't seem to be wanting t=
hat.<br></div><div><br></div><div>So you're just talking about "va=
lue semantics". `unique_ptr` and `shared_ptr` don't have value sem=
antics; they have reference semantics. Containers have value semantics.<br>=
</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/1927647f-a6aa-4136-bd17-1bd69243a197%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1927647f-a6aa-4136-bd17-1bd69243a197=
%40isocpp.org</a>.<br />
------=_Part_12692_947268232.1528251269725--
------=_Part_12691_166202413.1528251269725--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 5 Jun 2018 21:50:35 -0700 (PDT)
Raw View
------=_Part_37195_1401846771.1528260635917
Content-Type: multipart/alternative;
boundary="----=_Part_37196_447933328.1528260635918"
------=_Part_37196_447933328.1528260635918
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2018=E5=B9=B46=E6=9C=885=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=8C UTC+=
8=E4=B8=8B=E5=8D=885:13:46=EF=BC=8CRichard Hodges=E5=86=99=E9=81=93=EF=BC=
=9A
>
> This idea raises an interesting question.
>
> Why not make every object iterable?
>
> Object does not care how it is environed by something external.=20
Conceptionally bloating a well-known notion make confusion, and often=20
implies user needed more assumptions. Even it is seldom useful (e.g.=20
`container_of` macro), it is suspiciously costly to be built-in for all=20
cases.
If generality is needed, such capability can be exposed via *range*, which=
=20
is the intentional abstraction for such purpose.
=20
> Here's a quick and dirty implementation of std::begin and std::end for a=
=20
> std::optional
>
> http://coliru.stacked-crooked.com/a/7588796d45879675
>
> It seems to me that there is no reason that std::begin(int&) could not=20
> return a std::iterator_of_one_thing<int>, for example.
>
> Logically, it seems to me that a singular object is just a special case o=
f=20
> an array of zero or more objects.
>
>
> On Tue, 5 Jun 2018 at 09:27, Nevin Liber <ne...@eviloverlord.com=20
> <javascript:>> wrote:
>
>> On Tue, Jun 5, 2018 at 9:24 AM Corentin <corenti...@gmail.com=20
>> <javascript:>> wrote:
>>
>>>
>>> How would it compare to:
>>> std::array<T,1>
>>>
>>
>> Array models "exactly one element", not "at most one element".
>> --=20
>> Nevin ":-)" Liber <mailto:ne...@eviloverlord.com <javascript:>>=20
>> +1-847-691-1404
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> 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=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMX=
Q_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com=20
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BM=
XQ_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com?utm_medi=
um=3Demail&utm_source=3Dfooter>
>> .
>>
>
--=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/67cd7ae3-76b9-4b71-9557-3c458d863486%40isocpp.or=
g.
------=_Part_37196_447933328.1528260635918
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B46=E6=9C=885=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=8C UTC+8=E4=B8=8B=E5=8D=885:13:46=EF=BC=8CRichard Hodges=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">This idea raises an interesting question.<div><br></div><div>=
Why not make every object iterable?</div><div><br></div></div></blockquote>=
<div>Object does not care how it is environed by something external. Concep=
tionally bloating a well-known notion make confusion, and often implies use=
r needed more assumptions. Even it is seldom useful (e.g. `container_of` ma=
cro), it is suspiciously costly to be built-in for all cases.<br><br>If gen=
erality is needed, such capability can be exposed via <i>range</i>, which i=
s the intentional abstraction for such purpose.<br>=C2=A0<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Here&=
#39;s a quick and dirty implementation of std::begin and std::end for a std=
::optional</div><div><br></div><div><a href=3D"http://coliru.stacked-crooke=
d.com/a/7588796d45879675" target=3D"_blank" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fcoliru.stacke=
d-crooked.com%2Fa%2F7588796d45879675\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQj=
CNHHOrFwqQAL4jyntdxtPQK6LN_AnA';return true;" onclick=3D"this.href=3D&#=
39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcoliru.stacked-crooked.com%2=
Fa%2F7588796d45879675\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHHOrFwqQAL4jy=
ntdxtPQK6LN_AnA';return true;">http://coliru.stacked-crooked.<wbr>com/a=
/7588796d45879675</a></div><div><br></div><div>It seems to me that there is=
no reason that std::begin(int&) could not return a std::iterator_of_on=
e_thing<<wbr>int>, for example.</div><div><br></div><div>Logically, i=
t seems to me that a singular object is just a special case of an array of =
zero or more objects.</div><div><br><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, 5 Jun 2018 at 09:27, Nevin Liber <<a href=3D"javascript=
:" target=3D"_blank" gdf-obfuscated-mailto=3D"PSelHxQtBAAJ" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D=
"this.href=3D'javascript:';return true;">ne...@eviloverlord.com</a>=
> wrote:<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=
dir=3D"ltr">On Tue, Jun 5, 2018 at 9:24 AM Corentin <<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"PSelHxQtBAAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">corenti...@gmail.com</a=
>> wrote:<br><div class=3D"gmail_quote"><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 dir=3D"ltr"><br><div>How would it compare to:</div><=
div>std::array<T,1></div></div></blockquote><div><br></div><div>Array=
models "exactly one element", not "at most one element"=
;.</div><div>--=C2=A0<br></div></div><div dir=3D"ltr"><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PSelHxQtB=
AAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retu=
rn true;" onclick=3D"this.href=3D'javascript:';return true;">ne...@=
eviloverlord.com</a><wbr>> =C2=A0+1-847-691-1404</div></div></div></div>=
</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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"=
PSelHxQtBAAJ" 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"PSelHxQtBAAJ" 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/CAGg_6%2BMXQ_fSxv89egbfVHOPMcFFsU79F%=
2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMX=
Q_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com?utm_mediu=
m\x3demail\x26utm_source\x3dfooter';return true;" onclick=3D"this.href=
=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6=
%2BMXQ_fSxv89egbfVHOPMcFFsU79F%2BdE%3D54B3%2BkgF2upuw%40mail.gmail.com?utm_=
medium\x3demail\x26utm_source\x3dfooter';return true;">https://groups.g=
oogle.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/CAGg_6%2BMXQ_<wbr>fS=
xv89egbfVHOPMcFFsU79F%2BdE%<wbr>3D54B3%2BkgF2upuw%40mail.<wbr>gmail.com</a>=
..<br>
</blockquote></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/67cd7ae3-76b9-4b71-9557-3c458d863486%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/67cd7ae3-76b9-4b71-9557-3c458d863486=
%40isocpp.org</a>.<br />
------=_Part_37196_447933328.1528260635918--
------=_Part_37195_1401846771.1528260635917--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 5 Jun 2018 21:59:03 -0700 (PDT)
Raw View
------=_Part_45091_804747175.1528261143337
Content-Type: multipart/alternative;
boundary="----=_Part_45092_1704361356.1528261143337"
------=_Part_45092_1704361356.1528261143337
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2018=E5=B9=B46=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=8812:52:08=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazzuca wrote:
>>
>> There's really no reason not to -
>>
>
> That is a poor motivation for adding something to the standard. You need=
=20
> to provide a reason *to do* something, not a reason not to do it.
>
> Besides, it'd be much easier to just have a way to convert a=20
> `unique_ptr<T>` into a zero/one-element `span<T*>`. That's much better th=
an=20
> creating a whole new type just for doing iteration over a single element.=
=20
> That's what `span` is for, after all.
>
> Albeit I'm not against your whole point, this way is really bad a start t=
o=20
reject an idea. The design proposed is obviously not satisfying for many=20
more reasons about the design itself. The principle you used ("need to=20
provide a reason to do something") seems both over-powerful and too=20
indirect to express your concern explicitly, which in turn seems ironic=20
being against to "powerful" with no sufficient reasons.
=20
--=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/eefd36b4-24ed-493e-bd2f-8018d9cf33e5%40isocpp.or=
g.
------=_Part_45092_1704361356.1528261143337
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B46=E6=9C=886=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8812:52:08=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Tuesday, June 5, 2018 at 11:24:38 AM UTC-4, Nicole Mazzuca=
wrote:<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">There's=
really no reason not to -</div></blockquote><div><br></div><div>That is a =
poor motivation for adding something to the standard. You need to provide a=
reason <i>to do</i> something, not a reason not to do it.<br></div><div><b=
r></div><div>Besides, it'd be much easier to just have a way to convert=
a `unique_ptr<T>` into a zero/one-element `span<T*>`. That'=
;s much better than creating a whole new type just for doing iteration over=
a single element. That's what `span` is for, after all.<br></div><br><=
/div></blockquote><div>Albeit I'm not against your whole point, this wa=
y is really bad a start to reject an idea. The design proposed is obviously=
not satisfying for many more reasons about the design itself. The principl=
e you used ("need to provide a reason to do something") seems bot=
h over-powerful and too indirect to express your concern explicitly, which =
in turn seems ironic being against to "powerful" with no sufficie=
nt reasons.<br><br>=C2=A0<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/eefd36b4-24ed-493e-bd2f-8018d9cf33e5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/eefd36b4-24ed-493e-bd2f-8018d9cf33e5=
%40isocpp.org</a>.<br />
------=_Part_45092_1704361356.1528261143337--
------=_Part_45091_804747175.1528261143337--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 6 Jun 2018 01:14:53 -0400
Raw View
--00000000000038892e056df23f26
Content-Type: text/plain; charset="UTF-8"
On Tue, Jun 5, 2018 at 10:14 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, June 5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzuca wrote:
>>
>> Alright, apparently I haven't made my assumptions clear.
>>
>> I want value semantics because value semantics are nice, and almost
>> all types should be value semantic. This is the core idea of C++, I would
>> argue.
>>
>> Having a type like `box` allows you to keep your recursive types and
>> pimpl code simple, and correct.
>>
>
> OK, but what does it have to do with being a container? Why does a simple
> `value_ptr` type need the interface of a container? Can you provide one
> *genuine*, real-world example where this is useful? An example that a
> `span<T, 1>` couldn't resolve adequately?
>
>
I think part of the reasoning is that it is a (non C++, but English
language) _container_ by name, by construction, by the concept of a box
contains a thing.
But I think I agree that doesn't _necessarily_ mean it should have the C++
container interface.
Fat interfaces are bad, even when you're not using them as base classes. If
> you want to merge these two interfaces, you need to explain *why*.
>
> > Why does a container of one element needs to have deep copy semantics,
>> when every container of many elements doesn't have deep copy semantics?
>>
>> This sentence doesn't make sense. Every container has deep copy
>> semantics. I think you've misunderstood something? I said "deep copy"
>> as opposed to a shallow copy, like `shared_ptr`.
>>
>
> Apparently, I misunderstood. Generally speaking, when people say "deep
> copy" around the words "polymorphism", what they mean is "box<T> can store
> a pointer to a type U derived from T, and if I copy that box<T>, then it
> will create a new U instance in the new box<T> via <insert magic here>."
> But you don't seem to be wanting that.
>
I think "deep copy" is the right term here, but I can understand the
confusion.
So you're just talking about "value semantics". `unique_ptr` and
> `shared_ptr` don't have value semantics; they have reference semantics.
> Containers have value semantics.
>
raw pointer, unique_ptr and shared_ptr have value semantics - the value is
the address.
But they are typically used for the purpose of reference semantics on the
thing they point to.
--
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/CAOHCbiv_4EAA_eYsenaaqJjU8bBqbj5wFZ8YPqrY3LjKCX8L7A%40mail.gmail.com.
--00000000000038892e056df23f26
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Jun 5, 2018 at 10:14 PM, Nicol Bolas <span dir=3D"ltr"><<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><spa=
n class=3D"">On Tuesday, June 5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzuca w=
rote:<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>Alright,=
apparently I haven't made my assumptions clear.</div><div><br></div><d=
iv>I want value semantics because value semantics are nice, and almost</div=
><div>all types should be value semantic. This is the core idea of C++, I w=
ould</div><div>argue.<br></div><div><br></div><div>Having a type like `box`=
allows you to keep your recursive types and</div><div>pimpl code simple, a=
nd correct.</div></div></blockquote><div><br></div></span><div>OK, but what=
does it have to do with being a container? Why does a simple `value_ptr` t=
ype need the interface of a container? Can you provide one <i>genuine</i>, =
real-world example where this is useful? An example that a `span<T, 1>=
;` couldn't resolve adequately?<br></div><div><br></div></div></blockqu=
ote><div><br></div><div>I think part of the reasoning is that it is a (non =
C++, but English language) _container_ by name, by construction, by the con=
cept of a box contains a thing.</div><div>But I think I agree that doesn=
9;t _necessarily_ mean it should have the C++ container interface.<br></div=
><div><br></div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div></div><div>Fat interfaces are bad, even when you're not using=
them as base classes. If you want to merge these two interfaces, you need =
to explain <i>why</i>.<br></div><span class=3D""><div><br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div> > Why doe=
s a container of one element needs to have deep copy semantics,=20
when every container of many elements doesn't have deep copy semantics?=
</div><div><br></div><div>This sentence doesn't make sense. Every conta=
iner has deep copy</div><div>semantics. I think you've misunderstood so=
mething? I said "deep copy"</div><div>as opposed to a shallow cop=
y, like `shared_ptr`.</div></div></blockquote><div><br></div></span><div>Ap=
parently, I misunderstood. Generally speaking, when people say "deep c=
opy" around the words "polymorphism", what they mean is &quo=
t;box<T> can store a pointer to a type U derived from T, and if I cop=
y that box<T>, then it will create a new U instance in the new box<=
;T> via <insert magic here>." But you don't seem to be wa=
nting that.<br></div></div></blockquote><div><br></div><div>I think "d=
eep copy" is the right term here, but I can understand the confusion.<=
/div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><div>So you're just talking about "value semantics". `un=
ique_ptr` and `shared_ptr` don't have value semantics; they have refere=
nce semantics. Containers have value semantics.<br></div></div></blockquote=
><div><br></div><div>raw pointer, unique_ptr and shared_ptr have value sema=
ntics - the value is the address.</div><div>But they are typically used for=
the purpose of reference semantics on the thing they point to.</div><br></=
div><br>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signa=
ture"><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br></div></div>
</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/CAOHCbiv_4EAA_eYsenaaqJjU8bBqbj5wFZ8Y=
PqrY3LjKCX8L7A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiv_4EAA_eYs=
enaaqJjU8bBqbj5wFZ8YPqrY3LjKCX8L7A%40mail.gmail.com</a>.<br />
--00000000000038892e056df23f26--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 5 Jun 2018 22:23:56 -0700 (PDT)
Raw View
------=_Part_45667_2014493159.1528262636408
Content-Type: multipart/alternative;
boundary="----=_Part_45668_994094705.1528262636409"
------=_Part_45668_994094705.1528262636409
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2018=E5=B9=B46=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8A=E5=8D=8810:14:29=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=9A
>
> On Tuesday, June 5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzuca wrote:
>>
>> Alright, apparently I haven't made my assumptions clear.
>>
>> I want value semantics because value semantics are nice, and almost
>> all types should be value semantic. This is the core idea of C++, I woul=
d
>> argue.
>>
>> Having a type like `box` allows you to keep your recursive types and
>> pimpl code simple, and correct.
>>
>
> OK, but what does it have to do with being a container? Why does a simple=
=20
> `value_ptr` type need the interface of a container?
>
Agreed.
=20
> Can you provide one *genuine*, real-world example where this is useful?=
=20
> An example that a `span<T, 1>` couldn't resolve adequately?
>
> Fat interfaces are bad, even when you're not using them as base classes.=
=20
> If you want to merge these two interfaces, you need to explain *why*.
>
> > Why does a container of one element needs to have deep copy semantics,=
=20
>> when every container of many elements doesn't have deep copy semantics?
>>
>> This sentence doesn't make sense. Every container has deep copy
>> semantics. I think you've misunderstood something? I said "deep copy"
>> as opposed to a shallow copy, like `shared_ptr`.
>>
>
> Apparently, I misunderstood. Generally speaking, when people say "deep=20
> copy" around the words "polymorphism", what they mean is "box<T> can stor=
e=20
> a pointer to a type U derived from T, and if I copy that box<T>, then it=
=20
> will create a new U instance in the new box<T> via <insert magic here>."=
=20
> But you don't seem to be wanting that.
>
> So you're just talking about "value semantics". `unique_ptr` and=20
> `shared_ptr` don't have value semantics; they have reference semantics.=
=20
> Containers have value semantics.
>
> No. `unique_ptr` has value semantics even it can't be copied. It can be=
=20
*copy-initialized* and passed by value as other first-class objects without=
=20
knowledge about how an object interacts with its references.
--=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/858e1c7b-bdb1-4b74-b338-81bdcdaa4cc3%40isocpp.or=
g.
------=_Part_45668_994094705.1528262636409
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B46=E6=9C=886=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8A=E5=8D=8810:14:29=EF=BC=8CNicol Bolas=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">On Tuesday, June 5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzuca =
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>Alright=
, apparently I haven't made my assumptions clear.</div><div><br></div><=
div>I want value semantics because value semantics are nice, and almost</di=
v><div>all types should be value semantic. This is the core idea of C++, I =
would</div><div>argue.<br></div><div><br></div><div>Having a type like `box=
` allows you to keep your recursive types and</div><div>pimpl code simple, =
and correct.</div></div></blockquote><div><br></div><div>OK, but what does =
it have to do with being a container? Why does a simple `value_ptr` type ne=
ed the interface of a container?</div></div></blockquote><div>Agreed.<br><b=
r>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div> Can you provide one <i>genuine</i>, real-world example where this is=
useful? An example that a `span<T, 1>` couldn't resolve adequate=
ly?<br></div><div><br></div><div>Fat interfaces are bad, even when you'=
re not using them as base classes. If you want to merge these two interface=
s, you need to explain <i>why</i>.<br></div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div> > Why does a c=
ontainer of one element needs to have deep copy semantics,=20
when every container of many elements doesn't have deep copy semantics?=
</div><div><br></div><div>This sentence doesn't make sense. Every conta=
iner has deep copy</div><div>semantics. I think you've misunderstood so=
mething? I said "deep copy"</div><div>as opposed to a shallow cop=
y, like `shared_ptr`.</div></div></blockquote><div><br></div><div>Apparentl=
y, I misunderstood. Generally speaking, when people say "deep copy&quo=
t; around the words "polymorphism", what they mean is "box&l=
t;T> can store a pointer to a type U derived from T, and if I copy that =
box<T>, then it will create a new U instance in the new box<T> =
via <insert magic here>." But you don't seem to be wanting t=
hat.<br></div><div><br></div><div>So you're just talking about "va=
lue semantics". `unique_ptr` and `shared_ptr` don't have value sem=
antics; they have reference semantics. Containers have value semantics.<br>=
</div><br></div></blockquote><div>No. `unique_ptr` has value semantics even=
it can't be copied. It can be <i>copy-initialized</i> and passed by va=
lue as other first-class objects without knowledge about how an object inte=
racts with its references.<br><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/858e1c7b-bdb1-4b74-b338-81bdcdaa4cc3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/858e1c7b-bdb1-4b74-b338-81bdcdaa4cc3=
%40isocpp.org</a>.<br />
------=_Part_45668_994094705.1528262636409--
------=_Part_45667_2014493159.1528262636408--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 5 Jun 2018 23:03:10 -0700 (PDT)
Raw View
------=_Part_31404_901239067.1528264990328
Content-Type: multipart/alternative;
boundary="----=_Part_31405_1542966923.1528264990329"
------=_Part_31405_1542966923.1528264990329
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2018=E5=B9=B46=E6=9C=886=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC+=
8=E4=B8=8B=E5=8D=881:14:55=EF=BC=8CTony V E=E5=86=99=E9=81=93=EF=BC=9A
>
>
>
> On Tue, Jun 5, 2018 at 10:14 PM, Nicol Bolas <jmck...@gmail.com=20
> <javascript:>> wrote:
>
>> On Tuesday, June 5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzuca wrote:
>>>
>>> Alright, apparently I haven't made my assumptions clear.
>>>
>>> I want value semantics because value semantics are nice, and almost
>>> all types should be value semantic. This is the core idea of C++, I wou=
ld
>>> argue.
>>>
>>> Having a type like `box` allows you to keep your recursive types and
>>> pimpl code simple, and correct.
>>>
>>
>> OK, but what does it have to do with being a container? Why does a simpl=
e=20
>> `value_ptr` type need the interface of a container? Can you provide one=
=20
>> *genuine*, real-world example where this is useful? An example that a=20
>> `span<T, 1>` couldn't resolve adequately?
>>
>>
> I think part of the reasoning is that it is a (non C++, but English=20
> language) _container_ by name, by construction, by the concept of a box=
=20
> contains a thing.
> But I think I agree that doesn't _necessarily_ mean it should have the C+=
+=20
> container interface.
>
Well, to my experience, canonically, a box is an object contains a *value*=
=20
which is to be mutated, used mainly in impure languages with first-class=20
reference but no first-class referent. The term *value* is sometimes=20
interchange with *object *in those languages. But more specifically, the=20
value here is roughly equivalent to that in C, or prvalue in C++, which is =
*not=20
*the same to object in C or C++ which can keep identity. Moreover, a box is=
=20
usually kept away from more than one level of indirection, as a box of box=
=20
of value would be collapsed to a box of value, like lvalue reference in C++=
..
The key point of box in those languages is to provide capability of=20
indirection beyond so called value semantics. This seems be satisfying OP's=
=20
on-heap requirement. However, range access has nothing to do with box in=20
general. As I see, this is only occasionally true when the internal=20
representation of accessed range supported by the box is always the same=20
(e.g. *cons pairs*), which is exactly not the case in C++. So at least box=
=20
is not a good name for OP's purpose, if it is reasonable.
>
> Fat interfaces are bad, even when you're not using them as base classes.=
=20
>> If you want to merge these two interfaces, you need to explain *why*.
>>
>> > Why does a container of one element needs to have deep copy semantics,=
=20
>>> when every container of many elements doesn't have deep copy semantics?
>>>
>>> This sentence doesn't make sense. Every container has deep copy
>>> semantics. I think you've misunderstood something? I said "deep copy"
>>> as opposed to a shallow copy, like `shared_ptr`.
>>>
>>
>> Apparently, I misunderstood. Generally speaking, when people say "deep=
=20
>> copy" around the words "polymorphism", what they mean is "box<T> can sto=
re=20
>> a pointer to a type U derived from T, and if I copy that box<T>, then it=
=20
>> will create a new U instance in the new box<T> via <insert magic here>."=
=20
>> But you don't seem to be wanting that.
>>
>
> I think "deep copy" is the right term here, but I can understand the=20
> confusion.
>
> So you're just talking about "value semantics". `unique_ptr` and=20
>> `shared_ptr` don't have value semantics; they have reference semantics.=
=20
>> Containers have value semantics.
>>
>
> raw pointer, unique_ptr and shared_ptr have value semantics - the value i=
s=20
> the address.
> But they are typically used for the purpose of reference semantics on the=
=20
> thing they point to.
>
> Not quite true. As values in C++ are statically typed, there are no raw=
=20
addresses. Raw pointer has value semantics if it points a function or when=
=20
being subtyped to be always has a null value. Nonnull pointer to object can=
=20
has reference semantics on the object being pointed to. `unique_ptr` does=
=20
not has real reference semantics as either it is null or the object owned=
=20
is not accessible freely like other first-class objects. Note whether the=
=20
copy constructor of the object pointed to is called or not is not related=
=20
to the difference (and historically it is unspecified in C++ due to copy=20
elision).
=20
>
> --=20
> Be seeing you,
> Tony
>
--=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/a392edb9-e553-4570-8a0a-4b18f22a3061%40isocpp.or=
g.
------=_Part_31405_1542966923.1528264990329
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2018=E5=B9=B46=E6=9C=886=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=881:14:55=EF=BC=8CTony V E=E5=86=
=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div><br><div class=3D"gmail_quote">On Tue, Jun 5, 2018 at 10:=
14 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"L1wVFaBuBAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">jmck...@gmail.com</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Tuesday, June =
5, 2018 at 8:09:41 PM UTC-4, Nicole Mazzuca wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>Alright, apparently I haven't made=
my assumptions clear.</div><div><br></div><div>I want value semantics beca=
use value semantics are nice, and almost</div><div>all types should be valu=
e semantic. This is the core idea of C++, I would</div><div>argue.<br></div=
><div><br></div><div>Having a type like `box` allows you to keep your recur=
sive types and</div><div>pimpl code simple, and correct.</div></div></block=
quote><div><br></div></span><div>OK, but what does it have to do with being=
a container? Why does a simple `value_ptr` type need the interface of a co=
ntainer? Can you provide one <i>genuine</i>, real-world example where this =
is useful? An example that a `span<T, 1>` couldn't resolve adequa=
tely?<br></div><div><br></div></div></blockquote><div><br></div><div>I thin=
k part of the reasoning is that it is a (non C++, but English language) _co=
ntainer_ by name, by construction, by the concept of a box contains a thing=
..</div><div>But I think I agree that doesn't _necessarily_ mean it shou=
ld have the C++ container interface.<br></div></div></div></div></blockquot=
e><div><br>Well, to my experience, canonically, a box is an object contains=
a <i>value</i> which is to be mutated, used mainly in impure languages wit=
h first-class reference but no first-class referent. The term <i>value</i> =
is sometimes interchange with <i>object </i>in those languages. But more sp=
ecifically, the value here is roughly equivalent to that in C, or prvalue i=
n C++, which is <i>not </i>the same to object in C or C++ which can keep id=
entity. Moreover, a box is usually kept away from more than one level of in=
direction, as a box of box of value would be collapsed to a box of value, l=
ike lvalue reference in C++.<br><br>The key point of box in those languages=
is to provide capability of indirection beyond so called value semantics. =
This seems be satisfying OP's on-heap requirement. However, range acces=
s has nothing to do with box in general. As I see, this is only occasionall=
y true when the internal representation of accessed range supported by the =
box is always the same (e.g. <i>cons pairs</i>), which is exactly not the c=
ase in C++. So at least box is not a good name for OP's purpose, if it =
is reasonable.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div><br></div><d=
iv> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><d=
iv>Fat interfaces are bad, even when you're not using them as base clas=
ses. If you want to merge these two interfaces, you need to explain <i>why<=
/i>.<br></div><span><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div></div><div> > Why does a container of one element=
needs to have deep copy semantics,=20
when every container of many elements doesn't have deep copy semantics?=
</div><div><br></div><div>This sentence doesn't make sense. Every conta=
iner has deep copy</div><div>semantics. I think you've misunderstood so=
mething? I said "deep copy"</div><div>as opposed to a shallow cop=
y, like `shared_ptr`.</div></div></blockquote><div><br></div></span><div>Ap=
parently, I misunderstood. Generally speaking, when people say "deep c=
opy" around the words "polymorphism", what they mean is &quo=
t;box<T> can store a pointer to a type U derived from T, and if I cop=
y that box<T>, then it will create a new U instance in the new box<=
;T> via <insert magic here>." But you don't seem to be wa=
nting that.<br></div></div></blockquote><div><br></div><div>I think "d=
eep copy" is the right term here, but I can understand the confusion.<=
/div><div> <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><=
/div><div>So you're just talking about "value semantics". `un=
ique_ptr` and `shared_ptr` don't have value semantics; they have refere=
nce semantics. Containers have value semantics.<br></div></div></blockquote=
><div><br></div><div>raw pointer, unique_ptr and shared_ptr have value sema=
ntics - the value is the address.</div><div>But they are typically used for=
the purpose of reference semantics on the thing they point to.</div><br></=
div></div></div></blockquote><div>Not quite true. As values in C++ are stat=
ically typed, there are no raw addresses. Raw pointer has value semantics i=
f it points a function or when being subtyped to be always has a null value=
.. Nonnull pointer to object can has reference semantics on the object being=
pointed to. `unique_ptr` does not has real reference semantics as either i=
t is null or the object owned is not accessible freely like other first-cla=
ss objects. Note whether the copy constructor of the object pointed to is c=
alled or not is not related to the difference (and historically it is unspe=
cified in C++ due to copy elision).<br>=C2=A0<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><=
/div><br>-- <br><div><div dir=3D"ltr"><div>Be seeing you,<br></div>Tony<br>=
</div></div>
</div></div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/a392edb9-e553-4570-8a0a-4b18f22a3061%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a392edb9-e553-4570-8a0a-4b18f22a3061=
%40isocpp.org</a>.<br />
------=_Part_31405_1542966923.1528264990329--
------=_Part_31404_901239067.1528264990328--
.
Author: daltonmwoodard@gmail.com
Date: Tue, 5 Jun 2018 23:32:52 -0700 (PDT)
Raw View
------=_Part_45631_1875083924.1528266772148
Content-Type: multipart/alternative;
boundary="----=_Part_45632_1297289924.1528266772149"
------=_Part_45632_1297289924.1528266772149
Content-Type: text/plain; charset="UTF-8"
I think reframing the discussion may be helpful. Let's *define* `X<T>` to
be a container storing at most one object of type `T`. Let's also suppose
that the storage for that `T` is heap allocated, and that `X<>` (I'm
writing `X<>` as an abbreviation, not the empty template parameter list)
takes an optional second parameter satisfying Allocator, just to continue
the theme of "container" (remember, we're defining `X<>` to be a container *a
priori*). What are the consequences of this? First, `X<>` should support
the expected interface for container like objects. At a minimum this
implies the following:
- default constructible, destructible, copy constructible, copy
assignable, swappable, and equality comparable
- `X::[c]begin()`
- `X::[c]end()`
- `X::size()`
- `X::max_size()`
- `X::empty()`
For convenience we should also supply:
- `X::[c]rbegin()`
- `X::[c]rend()`
- relational comparison operators with lexicographic semantics, as is
idiomatic for many container types
Since `X<>` is a container it should support efficient move semantics. It
is, therefore, move constructible and move assignable. For similar reasons,
it should support efficient emplacement and idiomatic assignment (for
containers). Therefore, it has:
- `X::emplace()`
- `X::assign()`
Being an allocator aware container, `X<>` should also have:
- `X::get_allocator()`
- the appropriate constructor overloads for initialization with an
allocator instance
Now, for a container of zero or one objects, it is a little cumbersome to
always write `auto& e = *x.begin();` to obtain a reference to the contained
object, should one exist. Hence, for closure of the expressive basis it
seems reasonable to supply accessor methods. I nominate the following as
the name of the accessor:
- `X::get()`
Since we all appreciate idiomatic and consistent design, I say `X::get()`
ought to return a pointer, keeping with the theme that the contents are
heap allocated. And given that at most one object can be stored at a time,
it also seems appropriate to add:
- `X::operator*()`
Okay, finally, let's stand back and ask why we would want to use a type
with these semantics.
First, it fills (what I perceive to be) a gap in the the family of
traditional container types. A container with at most one element is, in
some real sense, the trivial container (barring an always-empty container,
which you might as well say is not a container at all). I think this can be
quite useful for generic programming for that reason.
The fact that the contents are heap allocated and that `X<>` has value
semantics means that `X<>` neatly solves the problem of how PIMPL idiom
state is stored.
Lastly, it also has a nice affordance for defining recursive data types,
which is only made possible by the fact that `X<>` stores its contents on
the heap.
Notice also that I have made no mention *whatsoever* of polymorphic types,
inheritance, or reference semantics in the above discussion, just as you
would expect for any discussion about containers. The entirety of the type
information about `X<T>`, both static and runtime, is captured by the name
`X<T>` -- end of story.
I can also nicely sidestep questions about why `X<T>` is a container type.
It is because I say so, by definition!
Finally, we need a good name for `X<>`. As Nicole mentioned, there are
several programming languages with types closing modeling the semantics
I've outlined above, each named "box". I think this name is suitable, since
the English term box connotes storage of some object(s).
So, lo and behold, we've obtained Nicole's `Box<T>` from first principles :)
--
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/a6347dea-6303-4ee6-8d20-51cc6466ae17%40isocpp.org.
------=_Part_45632_1297289924.1528266772149
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think reframing the discussion may be helpful. Let's=
=C2=A0<i>define</i>=C2=A0`X<T>` to be a container storing at most one=
object of type `T`. Let's also suppose that the storage for that `T` i=
s heap allocated, and that `X<>` (I'm writing `X<>` as an a=
bbreviation, not the empty template parameter list) takes an optional secon=
d parameter satisfying Allocator, just to continue the theme of "conta=
iner" (remember, we're defining `X<>` to be a container=C2=
=A0<i>a priori</i>). What are the consequences of this? First, `X<>` =
should support the expected interface for container like objects. At a mini=
mum this implies the following:<div><ul><li>default constructible, destruct=
ible, copy constructible, copy assignable, swappable, and equality comparab=
le</li><li>`X::[c]begin()`</li><li>`X::[c]end()`</li><li>`X::size()`</li><l=
i>`X::max_size()`</li><li>`X::empty()`</li></ul></div><div>For convenience =
we should also supply:<br></div><div><ul><li>`X::[c]rbegin()`</li><li>`X::[=
c]rend()`</li><li>relational comparison operators with lexicographic semant=
ics, as is idiomatic for many container types</li></ul><div>Since `X<>=
;` is a container it should support efficient move semantics. It is, theref=
ore, move constructible and move assignable. For similar reasons, it should=
support efficient emplacement and idiomatic assignment (for containers). T=
herefore, it has:</div><div><ul><li>`X::emplace()`</li><li>`X::assign()`</l=
i></ul></div><div><div>Being an allocator aware container, `X<>` shou=
ld also have:</div><div><ul><li>`X::get_allocator()`</li><li>the appropriat=
e constructor overloads for initialization with an allocator instance</li><=
/ul></div></div>Now, for a container of zero or one objects, it is a little=
cumbersome to always write `auto& e =3D *x.begin();` to obtain a refer=
ence to the contained object, should one exist. Hence, for closure of the e=
xpressive basis it seems reasonable to supply accessor methods. I nominate =
the following as the name of the accessor:</div><div><ul><li>`X::get()`</li=
></ul><div>Since we all appreciate idiomatic and consistent design, I say `=
X::get()` ought to return a pointer, keeping with the theme that the conten=
ts are heap allocated. And given that at most one object can be stored at a=
time, it also seems appropriate to add:</div></div><div><ul><li>`X::operat=
or*()`</li></ul><div>Okay, finally, let's stand back and ask why we wou=
ld want to use a type with these semantics.</div><div><br></div><div>First,=
it fills (what I perceive to be) a gap in the the family of traditional co=
ntainer types. A container with at most one element is, in some real sense,=
the trivial container (barring an always-empty container, which you might =
as well say is not a container at all). I think this can be quite useful fo=
r generic programming for that reason.</div><div><br></div><div>The fact th=
at the contents are heap allocated and that `X<>` has value semantics=
means that `X<>` neatly solves the problem of how PIMPL idiom state =
is stored.=C2=A0</div><div><br></div><div>Lastly, it also has a nice afford=
ance for defining recursive data types, which is only made possible by the =
fact that `X<>` stores its contents on the heap.</div></div><div><br>=
</div><div>Notice also that I have made no mention <i>whatsoever</i>=C2=A0o=
f polymorphic types, inheritance, or reference semantics in the above discu=
ssion, just as you would expect for any discussion about containers. The en=
tirety of the type information about `X<T>`, both static and runtime,=
is captured by the name `X<T>` -- end of story.</div><div><br></div>=
<div>I can also nicely sidestep questions about why `X<T>` is a conta=
iner type. It is because I say so, by definition!</div><div><br></div><div>=
Finally, we need a good name for `X<>`. As Nicole mentioned, there ar=
e several programming languages with types closing modeling the semantics I=
've outlined above, each named "box". I think this name is su=
itable, since the English term box connotes storage of some object(s).</div=
><div><br></div><div>So, lo and behold, we've obtained Nicole's `Bo=
x<T>` from first principles :)</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/a6347dea-6303-4ee6-8d20-51cc6466ae17%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a6347dea-6303-4ee6-8d20-51cc6466ae17=
%40isocpp.org</a>.<br />
------=_Part_45632_1297289924.1528266772149--
------=_Part_45631_1875083924.1528266772148--
.
Author: mihailnajdenov@gmail.com
Date: Wed, 6 Jun 2018 00:24:47 -0700 (PDT)
Raw View
------=_Part_36386_1416913957.1528269887945
Content-Type: multipart/alternative;
boundary="----=_Part_36387_1251292242.1528269887945"
------=_Part_36387_1251292242.1528269887945
Content-Type: text/plain; charset="UTF-8"
The problem is by 'containers' we really mean 'collections', we really do.
By definition a collection is something of more then one item, hence the
debate.
On Wednesday, June 6, 2018 at 9:32:52 AM UTC+3, daltonm...@gmail.com wrote:
>
> I think reframing the discussion may be helpful. Let's *define* `X<T>` to
> be a container storing at most one object of type `T`. Let's also suppose
> that the storage for that `T` is heap allocated, and that `X<>` (I'm
> writing `X<>` as an abbreviation, not the empty template parameter list)
> takes an optional second parameter satisfying Allocator, just to continue
> the theme of "container" (remember, we're defining `X<>` to be a container *a
> priori*). What are the consequences of this? First, `X<>` should support
> the expected interface for container like objects. At a minimum this
> implies the following:
>
> - default constructible, destructible, copy constructible, copy
> assignable, swappable, and equality comparable
> - `X::[c]begin()`
> - `X::[c]end()`
> - `X::size()`
> - `X::max_size()`
> - `X::empty()`
>
> For convenience we should also supply:
>
> - `X::[c]rbegin()`
> - `X::[c]rend()`
> - relational comparison operators with lexicographic semantics, as is
> idiomatic for many container types
>
> Since `X<>` is a container it should support efficient move semantics. It
> is, therefore, move constructible and move assignable. For similar reasons,
> it should support efficient emplacement and idiomatic assignment (for
> containers). Therefore, it has:
>
> - `X::emplace()`
> - `X::assign()`
>
> Being an allocator aware container, `X<>` should also have:
>
> - `X::get_allocator()`
> - the appropriate constructor overloads for initialization with an
> allocator instance
>
> Now, for a container of zero or one objects, it is a little cumbersome to
> always write `auto& e = *x.begin();` to obtain a reference to the contained
> object, should one exist. Hence, for closure of the expressive basis it
> seems reasonable to supply accessor methods. I nominate the following as
> the name of the accessor:
>
> - `X::get()`
>
> Since we all appreciate idiomatic and consistent design, I say `X::get()`
> ought to return a pointer, keeping with the theme that the contents are
> heap allocated. And given that at most one object can be stored at a time,
> it also seems appropriate to add:
>
> - `X::operator*()`
>
> Okay, finally, let's stand back and ask why we would want to use a type
> with these semantics.
>
> First, it fills (what I perceive to be) a gap in the the family of
> traditional container types. A container with at most one element is, in
> some real sense, the trivial container (barring an always-empty container,
> which you might as well say is not a container at all). I think this can be
> quite useful for generic programming for that reason.
>
> The fact that the contents are heap allocated and that `X<>` has value
> semantics means that `X<>` neatly solves the problem of how PIMPL idiom
> state is stored.
>
> Lastly, it also has a nice affordance for defining recursive data types,
> which is only made possible by the fact that `X<>` stores its contents on
> the heap.
>
> Notice also that I have made no mention *whatsoever* of polymorphic
> types, inheritance, or reference semantics in the above discussion, just as
> you would expect for any discussion about containers. The entirety of the
> type information about `X<T>`, both static and runtime, is captured by the
> name `X<T>` -- end of story.
>
> I can also nicely sidestep questions about why `X<T>` is a container type.
> It is because I say so, by definition!
>
> Finally, we need a good name for `X<>`. As Nicole mentioned, there are
> several programming languages with types closing modeling the semantics
> I've outlined above, each named "box". I think this name is suitable, since
> the English term box connotes storage of some object(s).
>
> So, lo and behold, we've obtained Nicole's `Box<T>` from first principles
> :)
>
--
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/f3d20f67-ff7c-441e-9d56-26424e639c39%40isocpp.org.
------=_Part_36387_1251292242.1528269887945
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The problem is by 'containers' we really mean=
'collections', we really do.=C2=A0</div><div><br></div><div>By def=
inition a collection is something of more then one item, hence the debate.<=
/div><br>On Wednesday, June 6, 2018 at 9:32:52 AM UTC+3, daltonm...@gmail.c=
om wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I th=
ink reframing the discussion may be helpful. Let's=C2=A0<i>define</i>=
=C2=A0`X<T>` to be a container storing at most one object of type `T`=
.. Let's also suppose that the storage for that `T` is heap allocated, a=
nd that `X<>` (I'm writing `X<>` as an abbreviation, not th=
e empty template parameter list) takes an optional second parameter satisfy=
ing Allocator, just to continue the theme of "container" (remembe=
r, we're defining `X<>` to be a container=C2=A0<i>a priori</i>). =
What are the consequences of this? First, `X<>` should support the ex=
pected interface for container like objects. At a minimum this implies the =
following:<div><ul><li>default constructible, destructible, copy constructi=
ble, copy assignable, swappable, and equality comparable</li><li>`X::[c]beg=
in()`</li><li>`X::[c]end()`</li><li>`X::size()`</li><li>`X::max_size()`</li=
><li>`X::empty()`</li></ul></div><div>For convenience we should also supply=
:<br></div><div><ul><li>`X::[c]rbegin()`</li><li>`X::[c]rend()`</li><li>rel=
ational comparison operators with lexicographic semantics, as is idiomatic =
for many container types</li></ul><div>Since `X<>` is a container it =
should support efficient move semantics. It is, therefore, move constructib=
le and move assignable. For similar reasons, it should support efficient em=
placement and idiomatic assignment (for containers). Therefore, it has:</di=
v><div><ul><li>`X::emplace()`</li><li>`X::assign()`</li></ul></div><div><di=
v>Being an allocator aware container, `X<>` should also have:</div><d=
iv><ul><li>`X::get_allocator()`</li><li>the appropriate constructor overloa=
ds for initialization with an allocator instance</li></ul></div></div>Now, =
for a container of zero or one objects, it is a little cumbersome to always=
write `auto& e =3D *x.begin();` to obtain a reference to the contained=
object, should one exist. Hence, for closure of the expressive basis it se=
ems reasonable to supply accessor methods. I nominate the following as the =
name of the accessor:</div><div><ul><li>`X::get()`</li></ul><div>Since we a=
ll appreciate idiomatic and consistent design, I say `X::get()` ought to re=
turn a pointer, keeping with the theme that the contents are heap allocated=
.. And given that at most one object can be stored at a time, it also seems =
appropriate to add:</div></div><div><ul><li>`X::operator*()`</li></ul><div>=
Okay, finally, let's stand back and ask why we would want to use a type=
with these semantics.</div><div><br></div><div>First, it fills (what I per=
ceive to be) a gap in the the family of traditional container types. A cont=
ainer with at most one element is, in some real sense, the trivial containe=
r (barring an always-empty container, which you might as well say is not a =
container at all). I think this can be quite useful for generic programming=
for that reason.</div><div><br></div><div>The fact that the contents are h=
eap allocated and that `X<>` has value semantics means that `X<>=
;` neatly solves the problem of how PIMPL idiom state is stored.=C2=A0</div=
><div><br></div><div>Lastly, it also has a nice affordance for defining rec=
ursive data types, which is only made possible by the fact that `X<>`=
stores its contents on the heap.</div></div><div><br></div><div>Notice als=
o that I have made no mention <i>whatsoever</i>=C2=A0of polymorphic types, =
inheritance, or reference semantics in the above discussion, just as you wo=
uld expect for any discussion about containers. The entirety of the type in=
formation about `X<T>`, both static and runtime, is captured by the n=
ame `X<T>` -- end of story.</div><div><br></div><div>I can also nicel=
y sidestep questions about why `X<T>` is a container type. It is beca=
use I say so, by definition!</div><div><br></div><div>Finally, we need a go=
od name for `X<>`. As Nicole mentioned, there are several programming=
languages with types closing modeling the semantics I've outlined abov=
e, each named "box". I think this name is suitable, since the Eng=
lish term box connotes storage of some object(s).</div><div><br></div><div>=
So, lo and behold, we've obtained Nicole's `Box<T>` from firs=
t principles :)</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/f3d20f67-ff7c-441e-9d56-26424e639c39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f3d20f67-ff7c-441e-9d56-26424e639c39=
%40isocpp.org</a>.<br />
------=_Part_36387_1251292242.1528269887945--
------=_Part_36386_1416913957.1528269887945--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 6 Jun 2018 08:29:50 -0700 (PDT)
Raw View
------=_Part_23099_1364460884.1528298990623
Content-Type: multipart/alternative;
boundary="----=_Part_23100_1466016450.1528298990624"
------=_Part_23100_1466016450.1528298990624
Content-Type: text/plain; charset="UTF-8"
On Wednesday, June 6, 2018 at 2:32:52 AM UTC-4, daltonm...@gmail.com wrote:
>
> First, it fills (what I perceive to be) a gap in the the family of
> traditional container types. A container with at most one element is, in
> some real sense, the trivial container (barring an always-empty container,
> which you might as well say is not a container at all). I think this can be
> quite useful for generic programming for that reason.
>
Why would a "trivial container" be "quite useful for generic programming"?
Can you provide something approaching real-world code where this would be
important? Something where creating a single-element `span` would not be
equally as effective?
The fact that the contents are heap allocated and that `X<>` has value
> semantics means that `X<>` neatly solves the problem of how PIMPL idiom
> state is stored.
>
> Lastly, it also has a nice affordance for defining recursive data types,
> which is only made possible by the fact that `X<>` stores its contents on
> the heap.
>
These are problems being solved *by accident*. Neither of these two use
cases use `X`'s container interface at all. A more focused type can solve
these problems:
1. Without relying on Allocator (if it needs memory allocation controls, we
can use something based on `memory_resource`).
2. Without the bloat of a container interface.
That a type can be used to solve a particular problem doesn't mean that it
is the best solution for that problem. `vector<T>` could also be used to
solve that problem, but you don't see people using it for that. Why?
Because these users need a value, not a container of values. Or even a
container of a value.
So you have 3 motivations for this type: a vague notion of "generic
programming could use it", and two concrete use cases that can better be
solved by another type. So why not solve the concrete problems with that
other type and leave this "box" behind?
--
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/d1cec38d-d434-4e10-8286-6111c29e41ee%40isocpp.org.
------=_Part_23100_1466016450.1528298990624
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, June 6, 2018 at 2:32:52 AM UTC-4, daltonm...=
@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"><div><div></div><div>First, it fills (what I perceive to be) a gap in t=
he the family of traditional container types. A container with at most one =
element is, in some real sense, the trivial container (barring an always-em=
pty container, which you might as well say is not a container at all). I th=
ink this can be quite useful for generic programming for that reason.</div>=
</div></div></blockquote><div><br></div><div>Why would a "trivial cont=
ainer" be "quite useful for generic programming"? Can you pr=
ovide something approaching real-world code where this would be important? =
Something where creating a single-element `span` would not be equally as ef=
fective?<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div><div></div><div>The fact that the contents are hea=
p allocated and that `X<>` has value semantics means that `X<>`=
neatly solves the problem of how PIMPL idiom state is stored.=C2=A0</div><=
div><br></div><div>Lastly, it also has a nice affordance for defining recur=
sive data types, which is only made possible by the fact that `X<>` s=
tores its contents on the heap.</div></div></div></blockquote><div><br></di=
v><div>These are problems being solved <i>by accident</i>. Neither of these=
two use cases use `X`'s container interface at all. A more focused typ=
e can solve these problems:</div><div><br></div><div>1. Without relying on =
Allocator (if it needs memory allocation controls, we can use something bas=
ed on `memory_resource`).</div><div>2. Without the bloat of a container int=
erface.</div><div><br></div><div>That a type can be used to solve a particu=
lar problem doesn't mean that it is the best solution for that problem.=
`vector<T>` could also be used to solve that problem, but you don=
9;t see people using it for that. Why? Because these users need a value, no=
t a container of values. Or even a container of a value.<br></div><div><br>=
</div><div>So you have 3 motivations for this type: a vague notion of "=
;generic programming could use it", and two concrete use cases that ca=
n better be solved by another type. So why not solve the concrete problems =
with that other type and leave this "box" behind?<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/d1cec38d-d434-4e10-8286-6111c29e41ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d1cec38d-d434-4e10-8286-6111c29e41ee=
%40isocpp.org</a>.<br />
------=_Part_23100_1466016450.1528298990624--
------=_Part_23099_1364460884.1528298990623--
.
Author: daltonmwoodard@gmail.com
Date: Wed, 6 Jun 2018 08:57:54 -0700 (PDT)
Raw View
------=_Part_47958_1392891827.1528300674832
Content-Type: multipart/alternative;
boundary="----=_Part_47959_404373198.1528300674832"
------=_Part_47959_404373198.1528300674832
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> First, it fills (what I perceive to be) a gap in the the family of=20
>> traditional container types. A container with at most one element is, in=
=20
>> some real sense, the trivial container (barring an always-empty containe=
r,=20
>> which you might as well say is not a container at all). I think this can=
be=20
>> quite useful for generic programming for that reason.
>>
>
> Why would a "trivial container" be "quite useful for generic programming"=
?=20
> Can you provide something approaching real-world code where this would be=
=20
> important? Something where creating a single-element `span` would not be=
=20
> equally as effective?
>
I think you're conflating storage vs view. A single element container is a =
*storage=20
mechanism*, whereas a `span<T, 1>` is a *view* that can be used in an=20
interface. Those are two fundamentally different things that you appear to=
=20
be confusing.
As for "something approaching real-world code", why don't you take a look=
=20
at how `Box<>` is used within the Rust compiler and standard library? Here,=
=20
I've taken the time to do the research for you :)
https://github.com/rust-lang/rust/search?utf8=3D=E2=9C=93&q=3DBox&type=3D
https://doc.rust-lang.org/std/boxed/struct.Box.html
=20
> The fact that the contents are heap allocated and that `X<>` has value=20
>> semantics means that `X<>` neatly solves the problem of how PIMPL idiom=
=20
>> state is stored.=20
>>
>> Lastly, it also has a nice affordance for defining recursive data types,=
=20
>> which is only made possible by the fact that `X<>` stores its contents o=
n=20
>> the heap.
>>
>
> These are problems being solved *by accident*. Neither of these two use=
=20
> cases use `X`'s container interface at all. A more focused type can solve=
=20
> these problems:
>
This is a fine point. I could see an argument for narrowing the interface=
=20
to container _only_ methods, leaving room for a `value_ptr` that does what=
=20
you've suggested.
=20
> 1. Without relying on Allocator (if it needs memory allocation controls,=
=20
> we can use something based on `memory_resource`).
>
You're misunderstand what a `memory_resource` is. It's not something to be=
=20
used independently of a `polymorphic_allocator<>`. Ergo, relying on an=20
allocator. A `memory_resource` isn't something to shuffle around willy=20
nilly in your program as a replacement for `new` and `delete`.
=20
> That a type can be used to solve a particular problem doesn't mean that i=
t=20
> is the best solution for that problem. `vector<T>` could also be used to=
=20
> solve that problem, but you don't see people using it for that. Why?=20
> Because these users need a value, not a container of values. Or even a=20
> container of a value.
>
This is true. Notice, however, that I did not say the _only_ means of=20
solving that problem is with a `box<>`, merely that it _can_ be solved.
=20
> So you have 3 motivations for this type: a vague notion of "generic=20
> programming could use it", and two concrete use cases that can better be=
=20
> solved by another type. So why not solve the concrete problems with that=
=20
> other type and leave this "box" behind?
>
Please don't confuse an offering of potential use cases with an exhaustive=
=20
list.=20
--=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/16b6e457-5b9c-4152-9ce8-b962201404ea%40isocpp.or=
g.
------=_Part_47959_404373198.1528300674832
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
></div><div>First, it fills (what I perceive to be) a gap in the the family=
of traditional container types. A container with at most one element is, i=
n some real sense, the trivial container (barring an always-empty container=
, which you might as well say is not a container at all). I think this can =
be quite useful for generic programming for that reason.</div></div></div><=
/blockquote><div><br></div><div>Why would a "trivial container" b=
e "quite useful for generic programming"? Can you provide somethi=
ng approaching real-world code where this would be important? Something whe=
re creating a single-element `span` would not be equally as effective?</div=
></div></blockquote><div><br></div><div>I think you're conflating stora=
ge vs view. A single element container is a <i>storage mechanism</i>, where=
as a `span<T, 1>` is a <i>view</i>=C2=A0that can be used in an interf=
ace. Those are two fundamentally different things that you appear to be con=
fusing.</div><div><br></div><div>As for "something approaching real-wo=
rld code", why don't you take a look at how `Box<>` is used =
within the Rust compiler and standard library? Here, I've taken the tim=
e to do the research for you :)</div><div><br></div><div>https://github.com=
/rust-lang/rust/search?utf8=3D=E2=9C=93&q=3DBox&type=3D</div><div><=
br></div><div>https://doc.rust-lang.org/std/boxed/struct.Box.html<br></div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div></div><div>The fact that the contents are heap allocated and that `X=
<>` has value semantics means that `X<>` neatly solves the prob=
lem of how PIMPL idiom state is stored.=C2=A0</div><div><br></div><div>Last=
ly, it also has a nice affordance for defining recursive data types, which =
is only made possible by the fact that `X<>` stores its contents on t=
he heap.</div></div></div></blockquote><div><br></div><div>These are proble=
ms being solved <i>by accident</i>. Neither of these two use cases use `X`&=
#39;s container interface at all. A more focused type can solve these probl=
ems:</div></div></blockquote><div><br></div><div>This is a fine point. I co=
uld see an argument for narrowing the interface to container _only_ methods=
, leaving room for a `value_ptr` that does what you've suggested.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>1. Without relying on Allocator (if it needs memory allocation con=
trols, we can use something based on `memory_resource`).</div></div></block=
quote><div><br></div><div>You're misunderstand what a `memory_resource`=
is. It's not something to be used independently of a `polymorphic_allo=
cator<>`. Ergo, relying on an allocator. A `memory_resource` isn'=
t something to shuffle around willy nilly in your program as a replacement =
for `new` and `delete`.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>That a type can be used to solve a pa=
rticular problem doesn't mean that it is the best solution for that pro=
blem. `vector<T>` could also be used to solve that problem, but you d=
on't see people using it for that. Why? Because these users need a valu=
e, not a container of values. Or even a container of a value.</div></div></=
blockquote><div><br></div><div>This is true. Notice, however, that I did no=
t say the _only_ means of solving that problem is with a `box<>`, mer=
ely that it _can_ be solved.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>So you have 3 motivat=
ions for this type: a vague notion of "generic programming could use i=
t", and two concrete use cases that can better be solved by another ty=
pe. So why not solve the concrete problems with that other type and leave t=
his "box" behind?<br></div></div></blockquote><div><br></div><div=
>Please don't confuse an offering of potential use cases with an exhaus=
tive list.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/16b6e457-5b9c-4152-9ce8-b962201404ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16b6e457-5b9c-4152-9ce8-b962201404ea=
%40isocpp.org</a>.<br />
------=_Part_47959_404373198.1528300674832--
------=_Part_47958_1392891827.1528300674832--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 6 Jun 2018 09:21:22 -0700 (PDT)
Raw View
------=_Part_24446_332457250.1528302082592
Content-Type: multipart/alternative;
boundary="----=_Part_24447_1497076495.1528302082592"
------=_Part_24447_1497076495.1528302082592
Content-Type: text/plain; charset="UTF-8"
On Wednesday, June 6, 2018 at 11:57:54 AM UTC-4, daltonm...@gmail.com wrote:
>
>
> First, it fills (what I perceive to be) a gap in the the family of
>>> traditional container types. A container with at most one element is, in
>>> some real sense, the trivial container (barring an always-empty container,
>>> which you might as well say is not a container at all). I think this can be
>>> quite useful for generic programming for that reason.
>>>
>>
>> Why would a "trivial container" be "quite useful for generic
>> programming"? Can you provide something approaching real-world code where
>> this would be important? Something where creating a single-element `span`
>> would not be equally as effective?
>>
>
> I think you're conflating storage vs view. A single element container is a *storage
> mechanism*, whereas a `span<T, 1>` is a *view* that can be used in an
> interface. Those are two fundamentally different things that you appear to
> be confusing.
>
I'm conflating nothing. I'm simply pointing out that you can get the effect
of such a container with our current tools.
Generally speaking, "generic programming" functions don't take containers;
they take *ranges*. A container may be a range, but algorithms don't care
about the container part of its interface; they care about the range part.
If I have an object, and I need to pass that object to some interface that
operates on a range, I will use `span<T, 1>` to do that. One can even write
a generic function that takes a pointer/reference and returns an
appropriate `span` of it (the pointer version returning a `dynamic_extent`
span, while the reference version would return a `span<T, 1>`).
By doing this, I am able to use any range-based generic algorithms based on
a range consisting of a single object. Why is this not a better solution
for using generic algorithms over a single object than creating a container
type for this?
As for "something approaching real-world code", why don't you take a look
> at how `Box<>` is used within the Rust compiler and standard library?
>
Because that would require being able to read Rust. And caring about what
decisions are being made in Rust.
We are after all talking about a C++ feature. You can't justify a C++
feature by saying nothing more than "Rust did it". You need to be able to
show why it is a good idea, where it is useful, preferably with code in a
language that we can all understand.
That's not to say that bringing up other languages is pointless. But you
can't just say "they did it, therefore we should". You need to say "they
did it, here's why it's a good idea, therefore we should." You're missing
the middle part.
--
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/ba1f68dc-f843-4890-9627-50f08aedf296%40isocpp.org.
------=_Part_24447_1497076495.1528302082592
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, June 6, 2018 at 11:57:54 AM UTC-4, daltonm..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><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"><blockquo=
te 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"><div><div></div><div>First,=
it fills (what I perceive to be) a gap in the the family of traditional co=
ntainer types. A container with at most one element is, in some real sense,=
the trivial container (barring an always-empty container, which you might =
as well say is not a container at all). I think this can be quite useful fo=
r generic programming for that reason.</div></div></div></blockquote><div><=
br></div><div>Why would a "trivial container" be "quite usef=
ul for generic programming"? Can you provide something approaching rea=
l-world code where this would be important? Something where creating a sing=
le-element `span` would not be equally as effective?</div></div></blockquot=
e><div><br></div><div>I think you're conflating storage vs view. A sing=
le element container is a <i>storage mechanism</i>, whereas a `span<T, 1=
>` is a <i>view</i>=C2=A0that can be used in an interface. Those are two=
fundamentally different things that you appear to be confusing.</div></div=
></blockquote><div><br></div><div>I'm conflating nothing. I'm simpl=
y pointing out that you can get the effect of such a container with our cur=
rent tools.<br></div><div><br></div><div>Generally speaking, "generic =
programming" functions don't take containers; they take <i>ranges<=
/i>. A container may be a range, but algorithms don't care about the co=
ntainer part of its interface; they care about the range part.</div><div><b=
r></div><div>If I have an object, and I need to pass that object to some in=
terface that operates on a range, I will use `span<T, 1>` to do that.=
One can even write a generic function that takes a pointer/reference and r=
eturns an appropriate `span` of it (the pointer version returning a `dynami=
c_extent` span, while the reference version would return a `span<T, 1>=
;`).</div><div><br></div><div>By doing this, I am able to use any range-bas=
ed generic algorithms based on a range consisting of a single object. Why i=
s this not a better solution for using generic algorithms over a single obj=
ect than creating a container type for this?</div><div></div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><=
div>As for "something approaching real-world code", why don't=
you take a look at how `Box<>` is used within the Rust compiler and =
standard library?</div></div></blockquote><div><br></div><div>Because that =
would require being able to read Rust. And caring about what decisions are =
being made in Rust.</div><div><br></div><div>We are after all talking about=
a C++ feature. You can't justify a C++ feature by saying nothing more =
than "Rust did it". You need to be able to show why it is a good =
idea, where it is useful, preferably with code in a language that we can al=
l understand.</div><div><br></div><div>That's not to say that bringing =
up other languages is pointless. But you can't just say "they did =
it, therefore we should". You need to say "they did it, here'=
s why it's a good idea, therefore we should." You're missing t=
he middle part.<br></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/ba1f68dc-f843-4890-9627-50f08aedf296%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ba1f68dc-f843-4890-9627-50f08aedf296=
%40isocpp.org</a>.<br />
------=_Part_24447_1497076495.1528302082592--
------=_Part_24446_332457250.1528302082592--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 13 Jun 2018 23:53:51 -0700 (PDT)
Raw View
------=_Part_1983_157404949.1528959231941
Content-Type: multipart/alternative;
boundary="----=_Part_1984_1368981558.1528959231941"
------=_Part_1984_1368981558.1528959231941
Content-Type: text/plain; charset="UTF-8"
Den tisdag 5 juni 2018 kl. 08:19:27 UTC+2 skrev Nicole Mazzuca:
>
> I've often wished for a container that can hold exactly one object -
> something
> like `std::unique_ptr`, but with value and container semantics. I want deep
> compare, deep copy, etc. However, there isn't any container that fits the
> bill
> in the current standard library. I'd like to gauge interest in having a
> type
> like this.
>
> I've called it `box`, because that's often how these things are referred
> to -
> Rust has `Box<T>`, Racket has `box`, Java has "Boxing". The name is
> completely
> up for bikeshedding. The interface is on my github, here:
>
> https://github.com/ubsan/ublib/blob/master/box/include/ublib/box.h#L50
>
> The sample implementation of the member functions is here:
>
> https://github.com/ubsan/ublib/blob/master/box/include/ublib/__box_impl.h
>
> I apologize for the mostly untested code, as well as any weird things that
> clang-format may have done! At this point, it's just a proof of concept.
> However, that is intended to be the "final" interface, so if there's
> anything in
> there you object to, or anything you'd like to see added, please speak up!
>
> I'm not certain this would be good for standardization, which is why I've
> placed
> it in the `ublib` namespace. I think, personally, it would be very useful
> for
> things like recursive types, as well as whenever one wants to put something
> behind a pointer, for whatever reason. `std::unique_ptr` is a useful tool,
> but
> it's fairly poor when one wants a proper C++ container type.
>
> Some notes:
>
> First - I'm not sure whether `reverse_iterator` should be a
> `std::reverse_iterator` - it works just fine as a normal `iterator`, given
> that
> there can either be zero or one elements, and a reversed range of zero or
> one
> elements is the same range. I felt as though `rbegin` and the like should
> be
> provided, however, as there's no reason not to have them.
>
> Second - This doesn't follow the requirements for AllocatorAwareContainer
> - it's
> a Container, which is aware of allocators, but it uses the new
> `std::allocator_arg_t` style interface.
>
> Third - Comparison is a lexicographic comparison.
>
> And I think that's it! If you have any questions, please ask away!
>
> Thanks for your time,
>
> Nicole Mazzuca
>
--
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/fef6abce-e695-40eb-b02a-6f18d1b4d311%40isocpp.org.
------=_Part_1984_1368981558.1528959231941
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Den tisdag 5 juni 2018 kl. 08:19:27 UTC+2 skrev Ni=
cole Mazzuca:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
I've often wished for a container that can hold exactly one object - so=
mething<br>like `std::unique_ptr`, but with value and container semantics. =
I want deep<br>compare, deep copy, etc. However, there isn't any contai=
ner that fits the bill<br>in the current standard library. I'd like to =
gauge interest in having a type<br>like this.<br><br>I've called it `bo=
x`, because that's often how these things are referred to -<br>Rust has=
`Box<T>`, Racket has `box`, Java has "Boxing". The name is=
completely<br>up for bikeshedding. The interface is on my github, here:<br=
><br><a href=3D"https://github.com/ubsan/ublib/blob/master/box/include/ubli=
b/box.h#L50" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fubsan%2Fubl=
ib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2Fbox.h%23L50\x26sa\x3dD\x26sntz=
\x3d1\x26usg\x3dAFQjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA';return true;" oncli=
ck=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub=
..com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2Fbox.h%23L50\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFN5ZLBnUe7OEb2xMq6c1DcrOIceA';r=
eturn true;">https://github.com/ubsan/<wbr>ublib/blob/master/box/include/<w=
br>ublib/box.h#L50</a><br><br>The sample implementation of the member funct=
ions is here:<br><br><a href=3D"https://github.com/ubsan/ublib/blob/master/=
box/include/ublib/__box_impl.h" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2Fublib%2F__box_impl.=
h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6Xs3M5qxTXYv83Pgg'=
;return true;" onclick=3D"this.href=3D'https://www.google.com/url?q\x3d=
https%3A%2F%2Fgithub.com%2Fubsan%2Fublib%2Fblob%2Fmaster%2Fbox%2Finclude%2F=
ublib%2F__box_impl.h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFvKvbc8lrPA6Xs=
3M5qxTXYv83Pgg';return true;">https://github.com/ubsan/<wbr>ublib/blob/=
master/box/include/<wbr>ublib/__box_impl.h</a><br><br>I apologize for the m=
ostly untested code, as well as any weird things that<br>clang-format may h=
ave done! At this point, it's just a proof of concept.<br>However, that=
is intended to be the "final" interface, so if there's anyth=
ing in<br>there you object to, or anything you'd like to see added, ple=
ase speak up!<br><br>I'm not certain this would be good for standardiza=
tion, which is why I've placed<br>it in the `ublib` namespace. I think,=
personally, it would be very useful for<br>things like recursive types, as=
well as whenever one wants to put something<br>behind a pointer, for whate=
ver reason. `std::unique_ptr` is a useful tool, but<br>it's fairly poor=
when one wants a proper C++ container type.<br><br>Some notes:<br><br>Firs=
t - I'm not sure whether `reverse_iterator` should be a<br>`std::revers=
e_iterator` - it works just fine as a normal `iterator`, given that<br>ther=
e can either be zero or one elements, and a reversed range of zero or one<b=
r>elements is the same range. I felt as though `rbegin` and the like should=
be<br>provided, however, as there's no reason not to have them.<br><br=
>Second - This doesn't follow the requirements for AllocatorAwareContai=
ner - it's<br>a Container, which is aware of allocators, but it uses th=
e new<br>`std::allocator_arg_t` style interface.<br><br>Third - Comparison =
is a lexicographic comparison.<br><br>And I think that's it! If you hav=
e any questions, please ask away!<br><br>Thanks for your time,<br><br>Nicol=
e Mazzuca<br></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fef6abce-e695-40eb-b02a-6f18d1b4d311%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fef6abce-e695-40eb-b02a-6f18d1b4d311=
%40isocpp.org</a>.<br />
------=_Part_1984_1368981558.1528959231941--
------=_Part_1983_157404949.1528959231941--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Thu, 14 Jun 2018 00:02:21 -0700 (PDT)
Raw View
------=_Part_2062_1022830615.1528959741355
Content-Type: multipart/alternative;
boundary="----=_Part_2063_1716222436.1528959741355"
------=_Part_2063_1716222436.1528959741355
Content-Type: text/plain; charset="UTF-8"
Can't the box<T> container be viewed as a one element instance of a general
capped_vector<T, N> type?
A capped_vector would allocate room for N elements but only construct them
when they are inserted. I think there are many use cases for such an
intermediate container between std::array and std::vector, and I hope that
the games/realtime group is working on a proposal.
I don't see a reason to allocate the element of box<T> on the heap if copy
semantics is deep anyway and it is not polymorphic. If it is polymorphic it
is similar to deep_ptr which has been proposed before but has severe
problems with actually being able to clone the pointee if it is possible to
copy back and forth between deep_ptr<BASE> and deep_ptr<SUB>, who knows
what it actually points to? This turned out to be a rabbit hole in the
absence of a standardized way of cloning any object.
--
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/42c9f24d-3ea5-4752-afcc-6139c9b29be6%40isocpp.org.
------=_Part_2063_1716222436.1528959741355
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Can't the box<T> container be viewed as a one el=
ement instance of a general capped_vector<T, N> type?<div><br></div><=
div>A capped_vector would allocate room for N elements but only construct t=
hem when they are inserted. I think there are many use cases for such an in=
termediate container between std::array and std::vector, and I hope that th=
e games/realtime group is working on a proposal.</div><div><br></div><div>I=
don't see a reason to allocate the element of box<T> on the heap=
if copy semantics is deep anyway and it is not polymorphic. If it is polym=
orphic it is similar to deep_ptr which has been proposed before but has sev=
ere problems with actually being able to clone the pointee if it is possibl=
e to copy back and forth between deep_ptr<BASE> and deep_ptr<SUB&g=
t;, who knows what it actually points to? This turned out to be a rabbit ho=
le in the absence of a standardized way of cloning any object.</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/42c9f24d-3ea5-4752-afcc-6139c9b29be6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/42c9f24d-3ea5-4752-afcc-6139c9b29be6=
%40isocpp.org</a>.<br />
------=_Part_2063_1716222436.1528959741355--
------=_Part_2062_1022830615.1528959741355--
.