Topic: Changing the return type of the containers
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Fri, 1 Jun 2018 16:50:40 +0100
Raw View
--000000000000f9a190056d968c20
Content-Type: text/plain; charset="UTF-8"
There is a school of thought that mutators should return void, because
there is no way to confuse them with things that return a changed copy
without changing the original.
On Fri, Jun 1, 2018 at 3:18 PM, 'Vlad from Moscow' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> I do not see a reason why the methods* resiz*e and* reserve* of standard
> containers have the return type *void*. In my opinion it would be much
> better if they would return a reference to themselves. Such a change will
> not influence on the existed code base.
>
> --
> 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/01f927fa-9176-44fa-
> b0a3-e17482f9996b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-44fa-b0a3-e17482f9996b%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/CAANG%3DkWUGAOfvhiae4FrBm15%2BbjQr9Yw_jdfDTMVdjEnmO0-9g%40mail.gmail.com.
--000000000000f9a190056d968c20
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There is a school of thought that mutators should return v=
oid, because there is no way to confuse them with things that return a chan=
ged copy without changing the original.</div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On Fri, Jun 1, 2018 at 3:18 PM, 'Vlad from =
Moscow' via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<=
a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@=
isocpp.org</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">I do not see a reason why the methods<b> resiz</b>e and<b> reserve=
</b> of standard containers have the return type <b>void</b>. In my opinion=
it would be much better if they would return a reference to themselves. Su=
ch a change will not influence on the existed code base.</div><span class=
=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-44fa-b0a3-e17482f9996b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/01f9=
27fa-9176-44fa-<wbr>b0a3-e17482f9996b%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></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/CAANG%3DkWUGAOfvhiae4FrBm15%2BbjQr9Yw=
_jdfDTMVdjEnmO0-9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWUGA=
Ofvhiae4FrBm15%2BbjQr9Yw_jdfDTMVdjEnmO0-9g%40mail.gmail.com</a>.<br />
--000000000000f9a190056d968c20--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 1 Jun 2018 17:18:32 +0100
Raw View
--0000000000000c4f2f056d96f0bd
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
When I first read the suggestion I was sceptical.
On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman <gasper.azman@gmail.com=
> wrote:
> There is a school of thought that mutators should return void, because
> there is no way to confuse them with things that return a changed copy
> without changing the original.
>
If they didn't return void, what would be best for calling mutators on
rvalues? Presumably this?
auto resize(size_t n) & -> vector&;
auto resize(size_t n) && -> vector&&;
This would allow code such as:
auto v =3D std::vector<int>().reserve(20);
Which is actually quite expressive, and starts to persuade me.
> On Fri, Jun 1, 2018 at 3:18 PM, 'Vlad from Moscow' via ISO C++ Standard -
> Future Proposals <std-proposals@isocpp.org> wrote:
>
>> I do not see a reason why the methods* resiz*e and* reserve* of standard
>> containers have the return type *void*. In my opinion it would be much
>> better if they would return a reference to themselves. Such a change wil=
l
>> not influence on the existed code base.
>>
>> --
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/01f927fa-91=
76-44fa-b0a3-e17482f9996b%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9=
176-44fa-b0a3-e17482f9996b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoo=
ter>
>> .
>>
>
> --
> 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/CAANG%3DkWUG=
AOfvhiae4FrBm15%2BbjQr9Yw_jdfDTMVdjEnmO0-9g%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWU=
GAOfvhiae4FrBm15%2BbjQr9Yw_jdfDTMVdjEnmO0-9g%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/CALvx3hYrHyjjCdPMqtSiF1C%2B2u6HC8crOHbb4OFtEZRRA=
%2B0_QA%40mail.gmail.com.
--0000000000000c4f2f056d96f0bd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">When I first read the suggestion I was sceptical.<br><br><=
div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, 1 Jun 2018 at 16:51, Ga=
=C5=A1per A=C5=BEman <<a href=3D"mailto:gasper.azman@gmail.com">gasper.a=
zman@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">There is a school of thought that mutators should return void, =
because there is no way to confuse them with things that return a changed c=
opy without changing the original.</div></blockquote><div><br></div><div>If=
they didn't return void, what would be best for calling mutators on rv=
alues? Presumably this?</div><div><br></div><div><div style=3D"color:rgb(34=
,34,34);font-size:13px;font-style:normal;font-variant-ligatures:normal;font=
-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start=
;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;ba=
ckground-color:rgb(255,255,255);text-decoration-style:initial;text-decorati=
on-color:initial"><font face=3D"monospace, monospace">auto resize(size_t n)=
& -> vector&;</font></div><font face=3D"monospace, monospace"><=
br class=3D"gmail-Apple-interchange-newline"></font><div style=3D"color:rgb=
(34,34,34);font-size:13px;font-style:normal;font-variant-ligatures:normal;f=
ont-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:st=
art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px=
;background-color:rgb(255,255,255);text-decoration-style:initial;text-decor=
ation-color:initial"><font face=3D"monospace, monospace">auto resize(size_t=
n) && -> vector&&;</font></div><br class=3D"gmail-Apple=
-interchange-newline">This would allow code such as:</div><div><br></div><d=
iv><font face=3D"monospace, monospace">auto v =3D std::vector<int>().=
reserve(20);</font></div><div><br></div><div>Which is actually quite expres=
sive, and starts to persuade me.</div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, =
Jun 1, 2018 at 3:18 PM, 'Vlad from Moscow' via ISO C++ Standard - F=
uture Proposals <span dir=3D"ltr"><<a href=3D"mailto:std-proposals@isocp=
p.org" target=3D"_blank">std-proposals@isocpp.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I do not see a reason why t=
he methods<b> resiz</b>e and<b> reserve</b> of standard containers have the=
return type <b>void</b>. In my opinion it would be much better if they wou=
ld return a reference to themselves. Such a change will not influence on th=
e existed code base.</div><span class=3D"m_5172040162190730346HOEnZb"><font=
color=3D"#888888">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@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/01f927fa-9176-44fa-b0a3-e17482f9996b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-=
44fa-b0a3-e17482f9996b%40isocpp.org</a>.<br>
</font></span></blockquote></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" 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/CAANG%3DkWUGAOfvhiae4FrBm15%2BbjQr9Yw=
_jdfDTMVdjEnmO0-9g%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/CAANG%3DkWUGAOfvhiae4FrBm15%2BbjQr9Yw_jdfDTMVdjEnmO0-9g%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/CALvx3hYrHyjjCdPMqtSiF1C%2B2u6HC8crOH=
bb4OFtEZRRA%2B0_QA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hYrHyjj=
CdPMqtSiF1C%2B2u6HC8crOHbb4OFtEZRRA%2B0_QA%40mail.gmail.com</a>.<br />
--0000000000000c4f2f056d96f0bd--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 1 Jun 2018 09:30:48 -0700 (PDT)
Raw View
------=_Part_10974_1910557080.1527870648740
Content-Type: multipart/alternative;
boundary="----=_Part_10975_346241569.1527870648740"
------=_Part_10975_346241569.1527870648740
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Friday, June 1, 2018 at 12:18:45 PM UTC-4, Richard Hodges wrote:
>
> When I first read the suggestion I was sceptical.
>
> On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman <gasper...@gmail.com=
=20
> <javascript:>> wrote:
>
>> There is a school of thought that mutators should return void, because=
=20
>> there is no way to confuse them with things that return a changed copy=
=20
>> without changing the original.
>>
>
> If they didn't return void, what would be best for calling mutators on=20
> rvalues? Presumably this?
>
> auto resize(size_t n) & -> vector&;
>
> auto resize(size_t n) && -> vector&&;
>
> This would allow code such as:
>
> auto v =3D std::vector<int>().reserve(20);
>
> Which is actually quite expressive, and starts to persuade me.
>
That's not a good argument for `resize`, since we already have matching=20
sizing constructors. What we ought to have is a reserving constructor for=
=20
`vector`.
I'm concerned about how this would increase the number of overloads for=20
these functions. `resize` in particular already has 2 overloads; your=20
suggestion would now require 4.
--=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/ffea28da-3c21-4966-bd18-0cbdf813d842%40isocpp.or=
g.
------=_Part_10975_346241569.1527870648740
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 12:18:45 PM UTC-4, Richard Hodg=
es 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">When=
I first read the suggestion I was sceptical.<br><br><div class=3D"gmail_qu=
ote"><div dir=3D"ltr">On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman &=
lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CxMj0=
PIJAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">ga=
sper...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">There is a school of thought that mutators should return voi=
d, because there is no way to confuse them with things that return a change=
d copy without changing the original.</div></blockquote><div><br></div><div=
>If they didn't return void, what would be best for calling mutators on=
rvalues? Presumably this?</div><div><br></div><div><div style=3D"color:rgb=
(34,34,34);font-size:13px;font-style:normal;font-weight:400;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;background-color:rgb(255,255,255)"><font face=3D"monos=
pace, monospace">auto resize(size_t n) & -> vector&;</font></div=
><font face=3D"monospace, monospace"><br></font><div style=3D"color:rgb(34,=
34,34);font-size:13px;font-style:normal;font-weight:400;letter-spacing:norm=
al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;=
word-spacing:0px;background-color:rgb(255,255,255)"><font face=3D"monospace=
, monospace">auto resize(size_t n) && -> vector&&;</font=
></div><br>This would allow code such as:</div><div><br></div><div><font fa=
ce=3D"monospace, monospace">auto v =3D std::vector<int>().reserve(20)=
<wbr>;</font></div><div><br></div><div>Which is actually quite expressive, =
and starts to persuade me.</div></div></div></blockquote><div><br></div><di=
v>That's not a good argument for `resize`, since we already have matchi=
ng sizing constructors. What we ought to have is a reserving constructor fo=
r `vector`.</div><div><br></div><div>I'm concerned about how this would=
increase the number of overloads for these functions. `resize` in particul=
ar already has 2 overloads; your suggestion would now require 4.<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/ffea28da-3c21-4966-bd18-0cbdf813d842%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ffea28da-3c21-4966-bd18-0cbdf813d842=
%40isocpp.org</a>.<br />
------=_Part_10975_346241569.1527870648740--
------=_Part_10974_1910557080.1527870648740--
.
Author: Richard Hodges <hodges.r@gmail.com>
Date: Fri, 1 Jun 2018 17:43:31 +0100
Raw View
--0000000000006eb7cc056d9749d6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, 1 Jun 2018 at 17:30, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Friday, June 1, 2018 at 12:18:45 PM UTC-4, Richard Hodges wrote:
>>
>> When I first read the suggestion I was sceptical.
>>
>> On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman <gasper...@gmail.com=
> wrote:
>>
>>> There is a school of thought that mutators should return void, because
>>> there is no way to confuse them with things that return a changed copy
>>> without changing the original.
>>>
>>
>> If they didn't return void, what would be best for calling mutators on
>> rvalues? Presumably this?
>>
>> auto resize(size_t n) & -> vector&;
>>
>> auto resize(size_t n) && -> vector&&;
>>
>> This would allow code such as:
>>
>> auto v =3D std::vector<int>().reserve(20);
>>
>> Which is actually quite expressive, and starts to persuade me.
>>
>
> That's not a good argument for `resize`, since we already have matching
> sizing constructors. What we ought to have is a reserving constructor for
> `vector`.
>
> I'm concerned about how this would increase the number of overloads for
> these functions. `resize` in particular already has 2 overloads; your
> suggestion would now require 4.
>
I share your concern. In the main I prefer free functions TBH. The standard
seems shy of them on the whole.
>
> --
> 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/ffea28da-3c2=
1-4966-bd18-0cbdf813d842%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ffea28da-3c=
21-4966-bd18-0cbdf813d842%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/CALvx3hZbvcsXqAbuHx%3DGaTLU80Kta1-VBByhgesFvQKWM=
Z%2B55g%40mail.gmail.com.
--0000000000006eb7cc056d9749d6
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 Fri=
, 1 Jun 2018 at 17:30, Nicol Bolas <<a href=3D"mailto:jmckesson@gmail.co=
m">jmckesson@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">On Friday, June 1, 2018 at 12:18:45 PM UTC-4, Richard H=
odges 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">When I=
first read the suggestion I was sceptical.<br><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman <=
;<a rel=3D"nofollow">gasper...@gmail.com</a>> wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr">There is a school of thought that mut=
ators should return void, because there is no way to confuse them with thin=
gs that return a changed copy without changing the original.</div></blockqu=
ote><div><br></div><div>If they didn't return void, what would be best =
for calling mutators on rvalues? Presumably this?</div><div><br></div><div>=
<div style=3D"color:rgb(34,34,34);font-size:13px;font-style:normal;font-wei=
ght:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transfo=
rm:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,25=
5)"><font face=3D"monospace, monospace">auto resize(size_t n) & -> v=
ector&;</font></div><font face=3D"monospace, monospace"><br></font><div=
style=3D"color:rgb(34,34,34);font-size:13px;font-style:normal;font-weight:=
400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:n=
one;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">=
<font face=3D"monospace, monospace">auto resize(size_t n) && -> =
vector&&;</font></div><br>This would allow code such as:</div><div>=
<br></div><div><font face=3D"monospace, monospace">auto v =3D std::vector&l=
t;int>().reserve(20);</font></div><div><br></div><div>Which is actually =
quite expressive, and starts to persuade me.</div></div></div></blockquote>=
<div><br></div><div>That's not a good argument for `resize`, since we a=
lready have matching sizing constructors. What we ought to have is a reserv=
ing constructor for `vector`.</div><div><br></div><div>I'm concerned ab=
out how this would increase the number of overloads for these functions. `r=
esize` in particular already has 2 overloads; your suggestion would now req=
uire 4.<br></div></div></blockquote><div><br></div><div>I share your concer=
n. In the main I prefer free functions TBH. The standard seems shy of them =
on the whole.</div><div>=C2=A0</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><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" 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/ffea28da-3c21-4966-bd18-0cbdf813d842%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ffea28da-3c21-=
4966-bd18-0cbdf813d842%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/CALvx3hZbvcsXqAbuHx%3DGaTLU80Kta1-VBB=
yhgesFvQKWMZ%2B55g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hZbvcsX=
qAbuHx%3DGaTLU80Kta1-VBByhgesFvQKWMZ%2B55g%40mail.gmail.com</a>.<br />
--0000000000006eb7cc056d9749d6--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Fri, 1 Jun 2018 20:24:22 +0200
Raw View
--0000000000008b16fd056d98b611
Content-Type: text/plain; charset="UTF-8"
I don't know a lot about ABI compatibility, but doesn't that break the ABI?
Especially for implementations like MSVC that mangle the return type?
On Fri, Jun 1, 2018 at 4:18 PM 'Vlad from Moscow' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> I do not see a reason why the methods* resiz*e and* reserve* of standard
> containers have the return type *void*. In my opinion it would be much
> better if they would return a reference to themselves. Such a change will
> not influence on the existed code base.
>
> --
> 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/01f927fa-9176-44fa-b0a3-e17482f9996b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-44fa-b0a3-e17482f9996b%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/CALmDwq1DK3uop_zXDsNPMdMB7staOr7tL-rK7ioD%3DhFDmrtSHg%40mail.gmail.com.
--0000000000008b16fd056d98b611
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't know a lot about ABI compatibility, but doesn&=
#39;t that break the ABI? Especially for implementations like MSVC that man=
gle the return type?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Fri, Jun 1, 2018 at 4:18 PM 'Vlad from Moscow' via ISO C++ Standa=
rd - Future Proposals <<a href=3D"mailto:std-proposals@isocpp.org">std-p=
roposals@isocpp.org</a>> wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr">I do not see a reason why the methods<b> resiz</b>e and<b>=
reserve</b> of standard containers have the return type <b>void</b>. In my=
opinion it would be much better if they would return a reference to themse=
lves. Such a change will not influence on the existed code base.</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/01f927fa-9176-44fa-b0a3-e17482f9996b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/01f927fa-9176-=
44fa-b0a3-e17482f9996b%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/CALmDwq1DK3uop_zXDsNPMdMB7staOr7tL-rK=
7ioD%3DhFDmrtSHg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1DK3uop_=
zXDsNPMdMB7staOr7tL-rK7ioD%3DhFDmrtSHg%40mail.gmail.com</a>.<br />
--0000000000008b16fd056d98b611--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Fri, 1 Jun 2018 15:33:37 -0700 (PDT)
Raw View
------=_Part_13504_1422983519.1527892417865
Content-Type: multipart/alternative;
boundary="----=_Part_13505_700678163.1527892417865"
------=_Part_13505_700678163.1527892417865
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Friday, June 1, 2018 at 9:18:45 AM UTC-7, Richard Hodges wrote:
>
> When I first read the suggestion I was sceptical.
>
> On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman <gasper...@gmail.com=
=20
> <javascript:>> wrote:
>
>> There is a school of thought that mutators should return void, because=
=20
>> there is no way to confuse them with things that return a changed copy=
=20
>> without changing the original.
>>
>
> If they didn't return void, what would be best for calling mutators on=20
> rvalues? Presumably this?
>
> auto resize(size_t n) & -> vector&;
>
> auto resize(size_t n) && -> vector&&;
>
> This would allow code such as:
>
> auto v =3D std::vector<int>().reserve(20);
>
> Which is actually quite expressive, and starts to persuade me.
>
I think you mean
auto resize(size_t n) && -> vector;
because otherwise you've just disabled copy elision.
Anyway, yeah, you're basically doubling the number of methods in `vector`=
=20
and introducing yet another overload resolution, for zero actual gain in=20
codegen.
If `resize()` were going to return anything, it should return the old value=
=20
of end(), and/or, a boolean indicator of whether reallocation happened.=20
Returning the `this` pointer (which the caller already has in a register by=
=20
definition) is just wasteful.
So, let's not do this.
=E2=80=93Arthur
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/00a5f681-aaef-4a48-800d-e2ab2a9ec0f1%40isocpp.or=
g.
------=_Part_13505_700678163.1527892417865
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 9:18:45 AM UTC-7, Richard Hodge=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">When =
I first read the suggestion I was sceptical.<br><br><div class=3D"gmail_quo=
te"><div dir=3D"ltr">On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman &l=
t;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"CxMj0P=
IJAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">gas=
per...@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">There is a school of thought that mutators should return void=
, because there is no way to confuse them with things that return a changed=
copy without changing the original.</div></blockquote><div><br></div><div>=
If they didn't return void, what would be best for calling mutators on =
rvalues? Presumably this?</div><div><br></div><div><div style=3D"color:rgb(=
34,34,34);font-size:13px;font-style:normal;font-weight:400;letter-spacing:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px;background-color:rgb(255,255,255)"><font face=3D"monosp=
ace, monospace">auto resize(size_t n) & -> vector&;</font></div>=
<font face=3D"monospace, monospace"><br></font><div style=3D"color:rgb(34,3=
4,34);font-size:13px;font-style:normal;font-weight:400;letter-spacing:norma=
l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px;background-color:rgb(255,255,255)"><font face=3D"monospace,=
monospace">auto resize(size_t n) && -> vector&&;</font>=
</div><br>This would allow code such as:</div><div><br></div><div><font fac=
e=3D"monospace, monospace">auto v =3D std::vector<int>().reserve(20)<=
wbr>;</font></div><div><br></div><div>Which is actually quite expressive, a=
nd starts to persuade me.</div></div></div></blockquote><div><br></div><div=
>I think you mean</div><div><br></div><div>=C2=A0 =C2=A0 auto resize(size_t=
n) && -> vector;</div><div><br></div><div>because otherwise you=
've just disabled copy elision.</div><div>Anyway, yeah, you're basi=
cally doubling the number of methods in `vector` and introducing yet anothe=
r overload resolution, for zero actual gain in codegen.</div><div>If `resiz=
e()` were going to return anything, it should return the old value of end()=
, and/or, a boolean indicator of whether reallocation happened. Returning t=
he `this` pointer (which the caller already has in a register by definition=
) is just wasteful.</div><div>So, let's not do this.</div><div><br></di=
v><div>=E2=80=93Arthur</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/00a5f681-aaef-4a48-800d-e2ab2a9ec0f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00a5f681-aaef-4a48-800d-e2ab2a9ec0f1=
%40isocpp.org</a>.<br />
------=_Part_13505_700678163.1527892417865--
------=_Part_13504_1422983519.1527892417865--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 1 Jun 2018 21:27:13 -0700 (PDT)
Raw View
------=_Part_15075_496494108.1527913633654
Content-Type: multipart/alternative;
boundary="----=_Part_15076_1939377454.1527913633655"
------=_Part_15076_1939377454.1527913633655
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Friday, June 1, 2018 at 6:33:37 PM UTC-4, Arthur O'Dwyer wrote:
>
> On Friday, June 1, 2018 at 9:18:45 AM UTC-7, Richard Hodges wrote:
>>
>> When I first read the suggestion I was sceptical.
>>
>> On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman <gasper...@gmail.com=
> wrote:
>>
>>> There is a school of thought that mutators should return void, because=
=20
>>> there is no way to confuse them with things that return a changed copy=
=20
>>> without changing the original.
>>>
>>
>> If they didn't return void, what would be best for calling mutators on=
=20
>> rvalues? Presumably this?
>>
>> auto resize(size_t n) & -> vector&;
>>
>> auto resize(size_t n) && -> vector&&;
>>
>> This would allow code such as:
>>
>> auto v =3D std::vector<int>().reserve(20);
>>
>> Which is actually quite expressive, and starts to persuade me.
>>
>
> I think you mean
>
> auto resize(size_t n) && -> vector;
>
> because otherwise you've just disabled copy elision.
>
You can't have elision in this case no matter what. Doing=20
`std::vector<int>().reset` will manifest a temporary. You can't elide that=
=20
temporary; the standard requires it to exist. `reset` will be given a=20
`this` pointer to that temporary.
If it returns an rvalue-reference to `*this`, then the eventual assignment=
=20
will move from the temporary to the destination.
If it returns a prvalue, that prvalue can only be generated by taking *this=
=20
and moving it into a stack object, right? Well, that move into the stack=20
object from *this can't be elided. Even if you did something like `return=
=20
vector<int>(std::move(*this))`, that cannot elide the move from `*this` to=
=20
the prvalue.
So it's best to just return the rvalue reference. It's a common idiom for=
=20
this sort of thing.
--=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/718689bc-178c-426e-9920-c250b495c39f%40isocpp.or=
g.
------=_Part_15076_1939377454.1527913633655
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Friday, June 1, 2018 at 6:33:37 PM UTC-4, Arthu=
r O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Friday, June 1, 2018 at 9:18:45 AM UTC-7, Richard Hodges wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">When I first read =
the suggestion I was sceptical.<br><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Fri, 1 Jun 2018 at 16:51, Ga=C5=A1per A=C5=BEman <<a rel=3D"=
nofollow">gasper...@gmail.com</a>> wrote:<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">There is a school of thought that mutators shoul=
d return void, because there is no way to confuse them with things that ret=
urn a changed copy without changing the original.</div></blockquote><div><b=
r></div><div>If they didn't return void, what would be best for calling=
mutators on rvalues? Presumably this?</div><div><br></div><div><div style=
=3D"color:rgb(34,34,34);font-size:13px;font-style:normal;font-weight:400;le=
tter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px;background-color:rgb(255,255,255)"><font =
face=3D"monospace, monospace">auto resize(size_t n) & -> vector&=
;</font></div><font face=3D"monospace, monospace"><br></font><div style=3D"=
color:rgb(34,34,34);font-size:13px;font-style:normal;font-weight:400;letter=
-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-=
space:normal;word-spacing:0px;background-color:rgb(255,255,255)"><font face=
=3D"monospace, monospace">auto resize(size_t n) && -> vector&=
;&;</font></div><br>This would allow code such as:</div><div><br></div>=
<div><font face=3D"monospace, monospace">auto v =3D std::vector<int>(=
).reserve(20)<wbr>;</font></div><div><br></div><div>Which is actually quite=
expressive, and starts to persuade me.</div></div></div></blockquote><div>=
<br></div><div>I think you mean</div><div><br></div><div>=C2=A0 =C2=A0 auto=
resize(size_t n) && -> vector;</div><div><br></div><div>because=
otherwise you've just disabled copy elision.</div></div></blockquote><=
div><br></div><div>You can't have elision in this case no matter what. =
Doing `std::vector<int>().reset` will manifest a temporary. You can&#=
39;t elide that temporary; the standard requires it to exist. `reset` will =
be given a `this` pointer to that temporary.<br></div><div><br></div><div>I=
f it returns an rvalue-reference to `*this`, then the eventual assignment w=
ill move from the temporary to the destination.</div><div><br></div><div>If=
it returns a prvalue, that prvalue can only be generated by taking *this a=
nd moving it into a stack object, right? Well, that move into the stack obj=
ect from *this can't be elided. Even if you did something like `return =
vector<int>(std::move(*this))`, that cannot elide the move from `*thi=
s` to the prvalue.<br></div><div><br></div><div>So it's best to just re=
turn the rvalue reference. It's a common idiom for this sort of thing.<=
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/718689bc-178c-426e-9920-c250b495c39f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/718689bc-178c-426e-9920-c250b495c39f=
%40isocpp.org</a>.<br />
------=_Part_15076_1939377454.1527913633655--
------=_Part_15075_496494108.1527913633654--
.
Author: Victor Dyachenko <victor.dyachenko@gmail.com>
Date: Mon, 4 Jun 2018 00:25:51 -0700 (PDT)
Raw View
------=_Part_2582_1141988072.1528097152115
Content-Type: multipart/alternative;
boundary="----=_Part_2583_1460551020.1528097152115"
------=_Part_2583_1460551020.1528097152115
Content-Type: text/plain; charset="UTF-8"
On Friday, June 1, 2018 at 5:18:47 PM UTC+3, Vlad from Moscow wrote:
>
> I do not see a reason why the methods* resiz*e and* reserve* of standard
> containers have the return type *void*. In my opinion it would be much
> better if they would return a reference to themselves.
>
Or size() and capacity() respectively?
--
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/252df17f-3435-4a5b-aabc-9833ef6d4086%40isocpp.org.
------=_Part_2583_1460551020.1528097152115
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, June 1, 2018 at 5:18:47 PM UTC+3, Vlad from Mos=
cow 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 d=
o not see a reason why the methods<b> resiz</b>e and<b> reserve</b> of stan=
dard containers have the return type <b>void</b>. In my opinion it would be=
much better if they would return a reference to themselves.</div></blockqu=
ote><div><br>Or size() and capacity() respectively?<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/252df17f-3435-4a5b-aabc-9833ef6d4086%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/252df17f-3435-4a5b-aabc-9833ef6d4086=
%40isocpp.org</a>.<br />
------=_Part_2583_1460551020.1528097152115--
------=_Part_2582_1141988072.1528097152115--
.