Topic: Query regarding desirability of a new container
Author: =?UTF-8?B?R2HFoXBlciBBxb5tYW4=?= <gasper.azman@gmail.com>
Date: Thu, 19 Jul 2018 10:16:03 +0100
Raw View
--000000000000157133057156a2e5
Content-Type: text/plain; charset="UTF-8"
I'd pretty strongly prefer a separate data structure.
The killer is the non-backwards compatibility of partial-list splices. I've
used that specific feature to great effect before (in fact, that's the only
reason I chose a list over vector). You MUST maintain iterator validity
over splices in lists, it's necessary for making sure everyone's LRU cache
implementations don't break :). So, basically, by doing anything to list,
you're killing the very points that they are most frequently used for,
since few uses of them are where they are weak (performance of most things
plf::list optimizes).
plf::list *can* be used to great effect, but only in a subset of scenarios
where std::list is useful (and some where it isn't because of its
prohibitive cost). This creates regions where one or the other is useful,
which says "two containers" to me.
G
On Thu, Jul 19, 2018 at 5:36 AM, Matthew Bentley <mattreecebentley@gmail.com
> wrote:
> I have a draft proposal (here <http://www.plflib.org/list1.htm>) about
> deprecating range-based splice in std::list and relaxing time complexity
> requirements for singular insertion/erasure from O(1) to O(1) amortised,
> in order to allow for implementations using contiguous node allocation
> such as plf::list, which have strong performance benefits over std::list.
>
> I have another draft proposal (also here <http://www.plflib.org/list2.htm>)
> which is the same thing, but proposes a new container
> (std::bidirectional_list, bikeshedding allowed) instead and deprecating
> std::list over time.
> Please read the benefits via the plf::list page
> <http://www.plflib.org/list.htm> or the second proposal, and understand
> the problems involved in using an allocator instead (also via plf::list
> page or second proposal), before writing a comment.
>
> Which would you prefer and why?
>
> Cheers,
> Matt
>
> --
> 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/be1fdc29-e122-46f3-
> b710-1b1993abdd4b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29-e122-46f3-b710-1b1993abdd4b%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%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com.
--000000000000157133057156a2e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'd pretty strongly prefer a separate data structure.<=
div><br></div><div>The killer is the non-backwards compatibility of partial=
-list splices. I've used that specific feature to great effect before (=
in fact, that's the only reason I chose a list over vector). You MUST m=
aintain iterator validity over splices in lists, it's necessary for mak=
ing sure everyone's LRU cache implementations don't break :). So, b=
asically, by doing anything to list, you're killing the very points tha=
t they are most frequently used for, since few uses of them are where they =
are weak (performance of most things plf::list optimizes).<div><br></div><d=
iv>plf::list *can* be used to great effect, but only in a subset of scenari=
os where std::list is useful (and some where it isn't because of its pr=
ohibitive cost). This creates regions where one or the other is useful, whi=
ch says "two containers" to me.</div><div><br></div><div>G</div><=
div><br></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote">On Thu, Jul 19, 2018 at 5:36 AM, Matthew Bentley <span dir=3D"ltr"=
><<a href=3D"mailto:mattreecebentley@gmail.com" target=3D"_blank">mattre=
ecebentley@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr">I have a draft proposal (<a href=3D"http://www.plflib.or=
g/list1.htm" target=3D"_blank">here</a>) about deprecating range-based spli=
ce in std::list and relaxing time complexity requirements for singular inse=
rtion/erasure from O(1) to O(1) amortised,<br>in order to allow for impleme=
ntations using contiguous node allocation such as plf::list, which have str=
ong performance benefits over std::list.<br><br>I have another draft propos=
al (also <a href=3D"http://www.plflib.org/list2.htm" target=3D"_blank">here=
</a>) which is the same thing, but proposes a new container (std::bidirecti=
onal_list, bikeshedding allowed) instead and deprecating std::list over tim=
e.<br><div>Please read the benefits via the <a href=3D"http://www.plflib.or=
g/list.htm" target=3D"_blank">plf::list page</a> or the second proposal,=20
and understand the problems involved in using an allocator instead (also
via plf::list page or second proposal), before writing a comment.</div><di=
v><br></div><div>Which would you prefer and why?</div><br>Cheers,<br>Matt <=
br><span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></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/be1fdc29-e122-46f3-b710-1b1993abdd4b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/be1f=
dc29-e122-46f3-<wbr>b710-1b1993abdd4b%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%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAw=
grxLbb1dcZiYP9fw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx4WLq=
CS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com</a>.<br />
--000000000000157133057156a2e5--
.
Author: Matt Bentley <mattreecebentley@gmail.com>
Date: Fri, 20 Jul 2018 10:21:31 +1200
Raw View
Thanks Gasper,
much appreciated.
My thought, as per the second paper was that std::forward_list covers a=20
lot of ground where std::list might be used for splicing, with fewer=20
side-effects in multithreaded apps. But of course it lacks backward=20
iteration. In your mind would you be strongly against deprecating=20
std::list over time, given forward lists?
Cheers,
Matt
On 19/07/2018 9:16 p.m., Ga=C5=A1per A=C5=BEman wrote:
> I'd pretty strongly prefer a separate data structure.
>=20
> The killer is the non-backwards compatibility of partial-list splices.=20
> I've used that specific feature to great effect before (in fact, that's=
=20
> the only reason I chose a list over vector). You MUST maintain iterator=
=20
> validity over splices in lists, it's necessary for making sure=20
> everyone's LRU cache implementations don't break :). So, basically, by=20
> doing anything to list, you're killing the very points that they are=20
> most frequently used for, since few uses of them are where they are weak=
=20
> (performance of most things plf::list optimizes).
>=20
> plf::list *can* be used to great effect, but only in a subset of=20
> scenarios where std::list is useful (and some where it isn't because of=
=20
> its prohibitive cost). This creates regions where one or the other is=20
> useful, which says "two containers" to me.
>=20
> G
>=20
>=20
> On Thu, Jul 19, 2018 at 5:36 AM, Matthew Bentley=20
> <mattreecebentley@gmail.com <mailto:mattreecebentley@gmail.com>> wrote:
>=20
> I have a draft proposal (here <http://www.plflib.org/list1.htm>)
> about deprecating range-based splice in std::list and relaxing time
> complexity requirements for singular insertion/erasure from O(1) to
> O(1) amortised,
> in order to allow for implementations using contiguous node
> allocation such as plf::list, which have strong performance benefits
> over std::list.
>=20
> I have another draft proposal (also here
> <http://www.plflib.org/list2.htm>) which is the same thing, but
> proposes a new container (std::bidirectional_list, bikeshedding
> allowed) instead and deprecating std::list over time.
> Please read the benefits via the plf::list page
> <http://www.plflib.org/list.htm> or the second proposal, and
> understand the problems involved in using an allocator instead (also
> via plf::list page or second proposal), before writing a comment.
>=20
> Which would you prefer and why?
>=20
> Cheers,
> Matt
>=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 email to std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29=
-e122-46f3-b710-1b1993abdd4b%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc2=
9-e122-46f3-b710-1b1993abdd4b%40isocpp.org?utm_medium=3Demail&utm_source=3D=
footer>.
>=20
>=20
> --=20
> You received this message because you are subscribed to a topic in the=20
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/9AeGHm9oMm0/=
unsubscribe.
> To unsubscribe from this group and all its topics, send an email to=20
> std-proposals+unsubscribe@isocpp.org=20
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org=20
> <mailto:std-proposals@isocpp.org>.
> To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx4=
WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com=20
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx=
4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com?utm_medium=3Dem=
ail&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/eb224183-9d37-8fe4-4dbc-e58c5e01bbce%40gmail.com=
..
.
Author: Ryan McDougall <mcdougall.ryan@gmail.com>
Date: Thu, 19 Jul 2018 17:14:25 -0700
Raw View
--0000000000008c5cbe0571632eb6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I wasn't able to read either paper (permissions issue?) -- either way
deprecating std::list because you covet the name is pretty much a
non-starter. Even if splicing was *actively broken* for some users there
would be others that rely on it. I believe deprecation is reserved for
things that are entirely broken by design.
If you'd like to propose a new list type I suggest you come from that
angle, and justify why multiple libraries should support your
implementation versus say a skip list or other novel and useful types.
Examples of code in the wild that would require your implementation to be
correct and maintainable are ideal.
On Thu, Jul 19, 2018 at 3:21 PM Matt Bentley <mattreecebentley@gmail.com>
wrote:
> Thanks Gasper,
> much appreciated.
> My thought, as per the second paper was that std::forward_list covers a
> lot of ground where std::list might be used for splicing, with fewer
> side-effects in multithreaded apps. But of course it lacks backward
> iteration. In your mind would you be strongly against deprecating
> std::list over time, given forward lists?
> Cheers,
> Matt
>
> On 19/07/2018 9:16 p.m., Ga=C5=A1per A=C5=BEman wrote:
> > I'd pretty strongly prefer a separate data structure.
> >
> > The killer is the non-backwards compatibility of partial-list splices.
> > I've used that specific feature to great effect before (in fact, that's
> > the only reason I chose a list over vector). You MUST maintain iterator
> > validity over splices in lists, it's necessary for making sure
> > everyone's LRU cache implementations don't break :). So, basically, by
> > doing anything to list, you're killing the very points that they are
> > most frequently used for, since few uses of them are where they are wea=
k
> > (performance of most things plf::list optimizes).
> >
> > plf::list *can* be used to great effect, but only in a subset of
> > scenarios where std::list is useful (and some where it isn't because of
> > its prohibitive cost). This creates regions where one or the other is
> > useful, which says "two containers" to me.
> >
> > G
> >
> >
> > On Thu, Jul 19, 2018 at 5:36 AM, Matthew Bentley
> > <mattreecebentley@gmail.com <mailto:mattreecebentley@gmail.com>> wrote:
> >
> > I have a draft proposal (here <http://www.plflib.org/list1.htm>)
> > about deprecating range-based splice in std::list and relaxing time
> > complexity requirements for singular insertion/erasure from O(1) to
> > O(1) amortised,
> > in order to allow for implementations using contiguous node
> > allocation such as plf::list, which have strong performance benefit=
s
> > over std::list.
> >
> > I have another draft proposal (also here
> > <http://www.plflib.org/list2.htm>) which is the same thing, but
> > proposes a new container (std::bidirectional_list, bikeshedding
> > allowed) instead and deprecating std::list over time.
> > Please read the benefits via the plf::list page
> > <http://www.plflib.org/list.htm> or the second proposal, and
> > understand the problems involved in using an allocator instead (als=
o
> > via plf::list page or second proposal), before writing a comment.
> >
> > Which would you prefer and why?
> >
> > Cheers,
> > Matt
> >
> > --
> > 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
> > <mailto:std-proposals+unsubscribe@isocpp.org>.
> > To post to this group, send email to std-proposals@isocpp.org
> > <mailto:std-proposals@isocpp.org>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29-e12=
2-46f3-b710-1b1993abdd4b%40isocpp.org
> > <
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29-e12=
2-46f3-b710-1b1993abdd4b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoote=
r
> >.
> >
> >
> > --
> > You received this message because you are subscribed to a topic in the
> > Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/9AeGHm9oMm0/=
unsubscribe
> .
> > To unsubscribe from this group and all its topics, send an email to
> > std-proposals+unsubscribe@isocpp.org
> > <mailto:std-proposals+unsubscribe@isocpp.org>.
> > To post to this group, send email to std-proposals@isocpp.org
> > <mailto:std-proposals@isocpp.org>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx4=
WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com
> > <
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx4=
WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com?utm_medium=3Dema=
il&utm_source=3Dfooter
> >.
>
> --
> 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/eb224183-9d3=
7-8fe4-4dbc-e58c5e01bbce%40gmail.com
> .
>
--=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/CAHn%2BA5P_zcwDhHBbCsLECQ3EzCuA%2B6xkg0D2c%3DWKE=
%3DB3GFoKiA%40mail.gmail.com.
--0000000000008c5cbe0571632eb6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wasn't able to read either paper (permissions issue?=
) -- either way deprecating std::list because you covet the name is pretty =
much a non-starter. Even if splicing was *actively broken* for some users t=
here would be others that rely on it. I believe deprecation is reserved for=
things that are entirely broken by design.<br><br>If you'd like to pro=
pose a new list type I suggest you come from that angle, and justify why mu=
ltiple libraries should support your implementation versus say a skip list =
or other novel and useful types. Examples of code in the wild that would re=
quire your implementation to be correct and maintainable are ideal.</div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Jul 19, 2018 at 3:21 =
PM Matt Bentley <<a href=3D"mailto:mattreecebentley@gmail.com">mattreece=
bentley@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">Th=
anks Gasper,<br>
much appreciated.<br>
My thought, as per the second paper was that std::forward_list covers a <br=
>
lot of ground where std::list might be used for splicing, with fewer <br>
side-effects in multithreaded apps. But of course it lacks backward <br>
iteration. In your mind would you be strongly against deprecating <br>
std::list over time, given forward lists?<br>
Cheers,<br>
Matt<br>
<br>
On 19/07/2018 9:16 p.m., Ga=C5=A1per A=C5=BEman wrote:<br>
> I'd pretty strongly prefer a separate data structure.<br>
> <br>
> The killer is the non-backwards compatibility of partial-list splices.=
<br>
> I've used that specific feature to great effect before (in fact, t=
hat's <br>
> the only reason I chose a list over vector). You MUST maintain iterato=
r <br>
> validity over splices in lists, it's necessary for making sure <br=
>
> everyone's LRU cache implementations don't break :). So, basic=
ally, by <br>
> doing anything to list, you're killing the very points that they a=
re <br>
> most frequently used for, since few uses of them are where they are we=
ak <br>
> (performance of most things plf::list optimizes).<br>
> <br>
> plf::list *can* be used to great effect, but only in a subset of <br>
> scenarios where std::list is useful (and some where it isn't becau=
se of <br>
> its prohibitive cost). This creates regions where one or the other is =
<br>
> useful, which says "two containers" to me.<br>
> <br>
> G<br>
> <br>
> <br>
> On Thu, Jul 19, 2018 at 5:36 AM, Matthew Bentley <br>
> <<a href=3D"mailto:mattreecebentley@gmail.com" target=3D"_blank">ma=
ttreecebentley@gmail.com</a> <mailto:<a href=3D"mailto:mattreecebentley@=
gmail.com" target=3D"_blank">mattreecebentley@gmail.com</a>>> wrote:<=
br>
> <br>
>=C2=A0 =C2=A0 =C2=A0I have a draft proposal (here <<a href=3D"http:/=
/www.plflib.org/list1.htm" rel=3D"noreferrer" target=3D"_blank">http://www.=
plflib.org/list1.htm</a>>)<br>
>=C2=A0 =C2=A0 =C2=A0about deprecating range-based splice in std::list a=
nd relaxing time<br>
>=C2=A0 =C2=A0 =C2=A0complexity requirements for singular insertion/eras=
ure from O(1) to<br>
>=C2=A0 =C2=A0 =C2=A0O(1) amortised,<br>
>=C2=A0 =C2=A0 =C2=A0in order to allow for implementations using contigu=
ous node<br>
>=C2=A0 =C2=A0 =C2=A0allocation such as plf::list, which have strong per=
formance benefits<br>
>=C2=A0 =C2=A0 =C2=A0over std::list.<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0I have another draft proposal (also here<br>
>=C2=A0 =C2=A0 =C2=A0<<a href=3D"http://www.plflib.org/list2.htm" rel=
=3D"noreferrer" target=3D"_blank">http://www.plflib.org/list2.htm</a>>) =
which is the same thing, but<br>
>=C2=A0 =C2=A0 =C2=A0proposes a new container (std::bidirectional_list, =
bikeshedding<br>
>=C2=A0 =C2=A0 =C2=A0allowed) instead and deprecating std::list over tim=
e.<br>
>=C2=A0 =C2=A0 =C2=A0Please read the benefits via the plf::list page<br>
>=C2=A0 =C2=A0 =C2=A0<<a href=3D"http://www.plflib.org/list.htm" rel=
=3D"noreferrer" target=3D"_blank">http://www.plflib.org/list.htm</a>> or=
the second proposal, and<br>
>=C2=A0 =C2=A0 =C2=A0understand the problems involved in using an alloca=
tor instead (also<br>
>=C2=A0 =C2=A0 =C2=A0via plf::list page or second proposal), before writ=
ing a comment.<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0Which would you prefer and why?<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0Cheers,<br>
>=C2=A0 =C2=A0 =C2=A0Matt<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0-- <br>
>=C2=A0 =C2=A0 =C2=A0You received this message because you are subscribe=
d to the Google<br>
>=C2=A0 =C2=A0 =C2=A0Groups "ISO C++ Standard - Future Proposals&qu=
ot; group.<br>
>=C2=A0 =C2=A0 =C2=A0To unsubscribe from this group and stop receiving e=
mails from it,<br>
>=C2=A0 =C2=A0 =C2=A0send an email to <a href=3D"mailto:std-proposals%2B=
unsubscribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp.=
org</a><br>
>=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:std-proposals%2Bunsubs=
cribe@isocpp.org" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a=
>>.<br>
>=C2=A0 =C2=A0 =C2=A0To post to this group, send email to <a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
><br>
>=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:std-proposals@isocpp.o=
rg" target=3D"_blank">std-proposals@isocpp.org</a>>.<br>
>=C2=A0 =C2=A0 =C2=A0To view this discussion on the web visit<br>
>=C2=A0 =C2=A0 =C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/d=
/msgid/std-proposals/be1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org" rel=
=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/=
msgid/std-proposals/be1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org</a><b=
r>
>=C2=A0 =C2=A0 =C2=A0<<a href=3D"https://groups.google.com/a/isocpp.o=
rg/d/msgid/std-proposals/be1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org?=
utm_medium=3Demail&utm_source=3Dfooter" rel=3D"noreferrer" target=3D"_b=
lank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29=
-e122-46f3-b710-1b1993abdd4b%40isocpp.org?utm_medium=3Demail&utm_source=
=3Dfooter</a>>.<br>
> <br>
> <br>
> -- <br>
> You received this message because you are subscribed to a topic in the=
<br>
> Google Groups "ISO C++ Standard - Future Proposals" group.<b=
r>
> To unsubscribe from this topic, visit <br>
> <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposal=
s/9AeGHm9oMm0/unsubscribe" rel=3D"noreferrer" target=3D"_blank">https://gro=
ups.google.com/a/isocpp.org/d/topic/std-proposals/9AeGHm9oMm0/unsubscribe</=
a>.<br>
> To unsubscribe from this group and all its topics, send an email to <b=
r>
> <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_b=
lank">std-proposals+unsubscribe@isocpp.org</a> <br>
> <mailto:<a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" t=
arget=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a> <br>
> <mailto:<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blan=
k">std-proposals@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-proposal=
s/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com" r=
el=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw=
%40mail.gmail.com</a> <br>
> <<a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.co=
m?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%=
3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com?utm_medium=
=3Demail&utm_source=3Dfooter</a>>.<br>
<br>
-- <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%2Bunsubscribe@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/eb224183-9d37-8fe4-4dbc-e58c5e01bbce%=
40gmail.com" rel=3D"noreferrer" target=3D"_blank">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/eb224183-9d37-8fe4-4dbc-e58c5e01bbce%40=
gmail.com</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/CAHn%2BA5P_zcwDhHBbCsLECQ3EzCuA%2B6xk=
g0D2c%3DWKE%3DB3GFoKiA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAHn%2BA5=
P_zcwDhHBbCsLECQ3EzCuA%2B6xkg0D2c%3DWKE%3DB3GFoKiA%40mail.gmail.com</a>.<br=
/>
--0000000000008c5cbe0571632eb6--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 19 Jul 2018 20:18:26 -0700 (PDT)
Raw View
------=_Part_4947_194333307.1532056706928
Content-Type: multipart/alternative;
boundary="----=_Part_4948_2142502570.1532056706928"
------=_Part_4948_2142502570.1532056706928
Content-Type: text/plain; charset="UTF-8"
On Thursday, July 19, 2018 at 8:14:42 PM UTC-4, Ryan McDougall wrote:
>
> I wasn't able to read either paper (permissions issue?) -- either way
> deprecating std::list because you covet the name is pretty much a
> non-starter. Even if splicing was *actively broken* for some users there
> would be others that rely on it. I believe deprecation is reserved for
> things that are entirely broken by design.
>
If that were true, `bind_1st/2nd` would still be around. They're not
broken; they've simply been superseded.
Now granted, the point made here about deprecating `std::list` still
applies; this `plf::list` does *not* supercede `std::list`'s functionality
(since it is not compatible with `std::list`'s requirements), so
deprecating it would be inappropriate.
If you'd like to propose a new list type I suggest you come from that
> angle, and justify why multiple libraries should support your
> implementation versus say a skip list or other novel and useful types.
> Examples of code in the wild that would require your implementation to be
> correct and maintainable are ideal.
>
>
--
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/1e575e06-377e-4d74-9450-98fd7c2281b4%40isocpp.org.
------=_Part_4948_2142502570.1532056706928
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 19, 2018 at 8:14:42 PM UTC-4, Ry=
an McDougall wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">I wasn't able to read either paper (permissions issue?) -- either=
way deprecating std::list because you covet the name is pretty much a non-=
starter. Even if splicing was *actively broken* for some users there would =
be others that rely on it. I believe deprecation is reserved for things tha=
t are entirely broken by design.<br></div></blockquote><div><br></div><div>=
If that were true, `bind_1st/2nd` would still be around. They're not br=
oken; they've simply been superseded.</div><div><br></div><div>Now gran=
ted, the point made here about deprecating `std::list` still applies; this =
`plf::list` does <i>not</i> supercede `std::list`'s functionality (sinc=
e it is not compatible with `std::list`'s requirements), so deprecating=
it would be inappropriate.<br></div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr">If you'd like to propose a new l=
ist type I suggest you come from that angle, and justify why multiple libra=
ries should support your implementation versus say a skip list or other nov=
el and useful types. Examples of code in the wild that would require your i=
mplementation to be correct and maintainable are ideal.</div><br></blockquo=
te></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/1e575e06-377e-4d74-9450-98fd7c2281b4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e575e06-377e-4d74-9450-98fd7c2281b4=
%40isocpp.org</a>.<br />
------=_Part_4948_2142502570.1532056706928--
------=_Part_4947_194333307.1532056706928--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Sat, 21 Jul 2018 17:45:13 -0700 (PDT)
Raw View
------=_Part_7886_778747037.1532220313230
Content-Type: multipart/alternative;
boundary="----=_Part_7887_1020400717.1532220313231"
------=_Part_7887_1020400717.1532220313231
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I don't covet the name.
Thanks for pointing out that the links were broken, they are corrected now.=
=20
Please read them if you wish to critique accurately.
On Friday, July 20, 2018 at 12:14:42 PM UTC+12, Ryan McDougall wrote:
>
> I wasn't able to read either paper (permissions issue?) -- either way=20
> deprecating std::list because you covet the name is pretty much a=20
> non-starter. Even if splicing was *actively broken* for some users there=
=20
> would be others that rely on it. I believe deprecation is reserved for=20
> things that are entirely broken by design.
>
> If you'd like to propose a new list type I suggest you come from that=20
> angle, and justify why multiple libraries should support your=20
> implementation versus say a skip list or other novel and useful types.=20
> Examples of code in the wild that would require your implementation to be=
=20
> correct and maintainable are ideal.
>
> On Thu, Jul 19, 2018 at 3:21 PM Matt Bentley <mattreec...@gmail.com=20
> <javascript:>> wrote:
>
>> Thanks Gasper,
>> much appreciated.
>> My thought, as per the second paper was that std::forward_list covers a=
=20
>> lot of ground where std::list might be used for splicing, with fewer=20
>> side-effects in multithreaded apps. But of course it lacks backward=20
>> iteration. In your mind would you be strongly against deprecating=20
>> std::list over time, given forward lists?
>> Cheers,
>> Matt
>>
>> On 19/07/2018 9:16 p.m., Ga=C5=A1per A=C5=BEman wrote:
>> > I'd pretty strongly prefer a separate data structure.
>> >=20
>> > The killer is the non-backwards compatibility of partial-list splices.=
=20
>> > I've used that specific feature to great effect before (in fact, that'=
s=20
>> > the only reason I chose a list over vector). You MUST maintain iterato=
r=20
>> > validity over splices in lists, it's necessary for making sure=20
>> > everyone's LRU cache implementations don't break :). So, basically, by=
=20
>> > doing anything to list, you're killing the very points that they are=
=20
>> > most frequently used for, since few uses of them are where they are=20
>> weak=20
>> > (performance of most things plf::list optimizes).
>> >=20
>> > plf::list *can* be used to great effect, but only in a subset of=20
>> > scenarios where std::list is useful (and some where it isn't because o=
f=20
>> > its prohibitive cost). This creates regions where one or the other is=
=20
>> > useful, which says "two containers" to me.
>> >=20
>> > G
>> >=20
>> >=20
>> > On Thu, Jul 19, 2018 at 5:36 AM, Matthew Bentley=20
>> > <mattreec...@gmail.com <javascript:> <mailto:mattreec...@gmail.com=20
>> <javascript:>>> wrote:
>> >=20
>> > I have a draft proposal (here <http://www.plflib.org/list1.htm>)
>> > about deprecating range-based splice in std::list and relaxing tim=
e
>> > complexity requirements for singular insertion/erasure from O(1) t=
o
>> > O(1) amortised,
>> > in order to allow for implementations using contiguous node
>> > allocation such as plf::list, which have strong performance benefi=
ts
>> > over std::list.
>> >=20
>> > I have another draft proposal (also here
>> > <http://www.plflib.org/list2.htm>) which is the same thing, but
>> > proposes a new container (std::bidirectional_list, bikeshedding
>> > allowed) instead and deprecating std::list over time.
>> > Please read the benefits via the plf::list page
>> > <http://www.plflib.org/list.htm> or the second proposal, and
>> > understand the problems involved in using an allocator instead (al=
so
>> > via plf::list page or second proposal), before writing a comment.
>> >=20
>> > Which would you prefer and why?
>> >=20
>> > Cheers,
>> > Matt
>> >=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 email to std-proposal...@isocpp.org <javascript:>
>> > <mailto:std-proposals+unsubscribe@isocpp.org <javascript:>>.
>> > To post to this group, send email to std-pr...@isocpp.org=20
>> <javascript:>
>> > <mailto: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/be1fdc29-e1=
22-46f3-b710-1b1993abdd4b%40isocpp.org
>> > <
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29-e1=
22-46f3-b710-1b1993abdd4b%40isocpp.org?utm_medium=3Demail&utm_source=3Dfoot=
er
>> >.
>> >=20
>> >=20
>> > --=20
>> > You received this message because you are subscribed to a topic in the=
=20
>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this topic, visit=20
>> >=20
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/9AeGHm9oMm0=
/unsubscribe
>> .
>> > To unsubscribe from this group and all its topics, send an email to=20
>> > std-proposal...@isocpp.org <javascript:>=20
>> > <mailto:std-proposals+unsubscribe@isocpp.org <javascript:>>.
>> > To post to this group, send email to std-pr...@isocpp.org <javascript:=
>=20
>> > <mailto:std-pr...@isocpp.org <javascript:>>.
>> > To view this discussion on the web visit=20
>> >=20
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx=
4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com=20
>> > <
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx=
4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com?utm_medium=3Dem=
ail&utm_source=3Dfooter
>> >.
>>
>> --=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/eb224183-9d=
37-8fe4-4dbc-e58c5e01bbce%40gmail.com
>> .
>>
>
--=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/26556543-6a2b-4c19-81e7-3144fd502d72%40isocpp.or=
g.
------=_Part_7887_1020400717.1532220313231
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I don't covet the name.</div><div>Thanks for poin=
ting out that the links were broken, they are corrected now. Please read th=
em if you wish to critique accurately.</div><div><br></div><br>On Friday, J=
uly 20, 2018 at 12:14:42 PM UTC+12, Ryan McDougall 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">I wasn't able to read eith=
er paper (permissions issue?) -- either way deprecating std::list because y=
ou covet the name is pretty much a non-starter. Even if splicing was *activ=
ely broken* for some users there would be others that rely on it. I believe=
deprecation is reserved for things that are entirely broken by design.<br>=
<br>If you'd like to propose a new list type I suggest you come from th=
at angle, and justify why multiple libraries should support your implementa=
tion versus say a skip list or other novel and useful types. Examples of co=
de in the wild that would require your implementation to be correct and mai=
ntainable are ideal.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">O=
n Thu, Jul 19, 2018 at 3:21 PM Matt Bentley <<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.=
href=3D'javascript:';return true;">mattreec...@gmail.com</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Thanks Gasper,<br>
much appreciated.<br>
My thought, as per the second paper was that std::forward_list covers a <br=
>
lot of ground where std::list might be used for splicing, with fewer <br>
side-effects in multithreaded apps. But of course it lacks backward <br>
iteration. In your mind would you be strongly against deprecating <br>
std::list over time, given forward lists?<br>
Cheers,<br>
Matt<br>
<br>
On 19/07/2018 9:16 p.m., Ga=C5=A1per A=C5=BEman wrote:<br>
> I'd pretty strongly prefer a separate data structure.<br>
> <br>
> The killer is the non-backwards compatibility of partial-list splices.=
<br>
> I've used that specific feature to great effect before (in fact, t=
hat's <br>
> the only reason I chose a list over vector). You MUST maintain iterato=
r <br>
> validity over splices in lists, it's necessary for making sure <br=
>
> everyone's LRU cache implementations don't break :). So, basic=
ally, by <br>
> doing anything to list, you're killing the very points that they a=
re <br>
> most frequently used for, since few uses of them are where they are we=
ak <br>
> (performance of most things plf::list optimizes).<br>
> <br>
> plf::list *can* be used to great effect, but only in a subset of <br>
> scenarios where std::list is useful (and some where it isn't becau=
se of <br>
> its prohibitive cost). This creates regions where one or the other is =
<br>
> useful, which says "two containers" to me.<br>
> <br>
> G<br>
> <br>
> <br>
> On Thu, Jul 19, 2018 at 5:36 AM, Matthew Bentley <br>
> <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"RMMoARgFAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return tru=
e;">mattreec...@gmail.com</a> <mailto:<a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">mattreec...@<wbr>gmail.com</a>>> =
wrote:<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0I have a draft proposal (here <<a href=3D"http:/=
/www.plflib.org/list1.htm" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.plflib=
..org%2Flist1.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHpgw1IVpOFMx7aPAI1=
ctH_s3_6XQ';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\x3dhttp%3A%2F%2Fwww.plflib.org%2Flist1.htm\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNHpgw1IVpOFMx7aPAI1ctH_s3_6XQ';return true;">http://w=
ww.plflib.org/list1.<wbr>htm</a>>)<br>
>=C2=A0 =C2=A0 =C2=A0about deprecating range-based splice in std::list a=
nd relaxing time<br>
>=C2=A0 =C2=A0 =C2=A0complexity requirements for singular insertion/eras=
ure from O(1) to<br>
>=C2=A0 =C2=A0 =C2=A0O(1) amortised,<br>
>=C2=A0 =C2=A0 =C2=A0in order to allow for implementations using contigu=
ous node<br>
>=C2=A0 =C2=A0 =C2=A0allocation such as plf::list, which have strong per=
formance benefits<br>
>=C2=A0 =C2=A0 =C2=A0over std::list.<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0I have another draft proposal (also here<br>
>=C2=A0 =C2=A0 =C2=A0<<a href=3D"http://www.plflib.org/list2.htm" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fwww.plflib.org%2Flist2.htm\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNE5evTNnr7YRZ2SOxOC-lsvG67dmQ';return true;" on=
click=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.p=
lflib.org%2Flist2.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE5evTNnr7YRZ2=
SOxOC-lsvG67dmQ';return true;">http://www.plflib.org/list2.<wbr>htm</a>=
>) which is the same thing, but<br>
>=C2=A0 =C2=A0 =C2=A0proposes a new container (std::bidirectional_list, =
bikeshedding<br>
>=C2=A0 =C2=A0 =C2=A0allowed) instead and deprecating std::list over tim=
e.<br>
>=C2=A0 =C2=A0 =C2=A0Please read the benefits via the plf::list page<br>
>=C2=A0 =C2=A0 =C2=A0<<a href=3D"http://www.plflib.org/list.htm" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.=
google.com/url?q\x3dhttp%3A%2F%2Fwww.plflib.org%2Flist.htm\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNFHsJxOjHlcLqRSrpUxJ6vMXVwzUA';return true;" onc=
lick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.pl=
flib.org%2Flist.htm\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFHsJxOjHlcLqRSr=
pUxJ6vMXVwzUA';return true;">http://www.plflib.org/list.<wbr>htm</a>>=
; or the second proposal, and<br>
>=C2=A0 =C2=A0 =C2=A0understand the problems involved in using an alloca=
tor instead (also<br>
>=C2=A0 =C2=A0 =C2=A0via plf::list page or second proposal), before writ=
ing a comment.<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0Which would you prefer and why?<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0Cheers,<br>
>=C2=A0 =C2=A0 =C2=A0Matt<br>
> <br>
>=C2=A0 =C2=A0 =C2=A0-- <br>
>=C2=A0 =C2=A0 =C2=A0You received this message because you are subscribe=
d to the Google<br>
>=C2=A0 =C2=A0 =C2=A0Groups "ISO C++ Standard - Future Proposals&qu=
ot; group.<br>
>=C2=A0 =C2=A0 =C2=A0To unsubscribe from this group and stop receiving e=
mails from it,<br>
>=C2=A0 =C2=A0 =C2=A0send an email to <a href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">std-proposal...@<wbr>isocpp.org</a><br>
>=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">std-proposals+<wbr>unsubscribe@isocpp.org</a>=
>.<br>
>=C2=A0 =C2=A0 =C2=A0To post to this group, send email to <a href=3D"jav=
ascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"RMMoARgFAwAJ" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'javascript:';return true;" onc=
lick=3D"this.href=3D'javascript:';return true;">std-pr...@isocpp.or=
g</a><br>
>=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">std-pr...@isocpp.<wbr>org</a>>.<br>
>=C2=A0 =C2=A0 =C2=A0To view this discussion on the web visit<br>
>=C2=A0 =C2=A0 =C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/d=
/msgid/std-proposals/be1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org" rel=
=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://gro=
ups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29-e122-46f3-b710-1=
b1993abdd4b%40isocpp.org';return true;" onclick=3D"this.href=3D'htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/be1fdc29-e122-46f=
3-b710-1b1993abdd4b%40isocpp.org';return true;">https://groups.google.c=
om/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/be1fdc29-e122-46f3-<wbr>b71=
0-1b1993abdd4b%40isocpp.org</a><br>
>=C2=A0 =C2=A0 =C2=A0<<a href=3D"https://groups.google.com/a/isocpp.o=
rg/d/msgid/std-proposals/be1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org?=
utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" target=3D"_bla=
nk" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/be1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org?utm=
_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick=3D"this=
..href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b=
e1fdc29-e122-46f3-b710-1b1993abdd4b%40isocpp.org?utm_medium\x3demail\x26utm=
_source\x3dfooter';return true;">https://groups.google.com/a/<wbr>isocp=
p.org/d/msgid/std-<wbr>proposals/be1fdc29-e122-46f3-<wbr>b710-1b1993abdd4b%=
40isocpp.<wbr>org?utm_medium=3Demail&utm_<wbr>source=3Dfooter</a>>.<=
br>
> <br>
> <br>
> -- <br>
> You received this message because you are subscribed to a topic in the=
<br>
> Google Groups "ISO C++ Standard - Future Proposals" group.<b=
r>
> To unsubscribe from this topic, visit <br>
> <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposal=
s/9AeGHm9oMm0/unsubscribe" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/topic/std-pro=
posals/9AeGHm9oMm0/unsubscribe';return true;" onclick=3D"this.href=3D&#=
39;https://groups.google.com/a/isocpp.org/d/topic/std-proposals/9AeGHm9oMm0=
/unsubscribe';return true;">https://groups.google.com/a/<wbr>isocpp.org=
/d/topic/std-<wbr>proposals/9AeGHm9oMm0/<wbr>unsubscribe</a>.<br>
> To unsubscribe from this group and all its topics, send an email to <b=
r>
> <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"RMM=
oARgFAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:'=
;;return true;" onclick=3D"this.href=3D'javascript:';return true;">=
std-proposal...@<wbr>isocpp.org</a> <br>
> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">std-proposals+<wbr>unsubscribe@isocpp.org</a>>.<br>
> To post to this group, send email to <a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">std-pr...@isocpp.org</a> <br>
> <mailto:<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"RMMoARgFAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';ret=
urn true;">std-pr...@isocpp.<wbr>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-proposal=
s/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com" r=
el=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D'https://g=
roups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkWx4WLqCS4MntUj=
voLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.com';return true;" onclick=
=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-pro=
posals/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.c=
om';return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/s=
td-<wbr>proposals/CAANG%<wbr>3DkWx4WLqCS4MntUjvoLpmyiTZAfBA<wbr>wgrxLbb1dcZ=
iYP9fw%40mail.<wbr>gmail.com</a> <br>
> <<a href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw%40mail.gmail.co=
m?utm_medium=3Demail&utm_source=3Dfooter" rel=3D"nofollow" target=3D"_b=
lank" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.or=
g/d/msgid/std-proposals/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9=
fw%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return=
true;" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/=
d/msgid/std-proposals/CAANG%3DkWx4WLqCS4MntUjvoLpmyiTZAfBAwgrxLbb1dcZiYP9fw=
%40mail.gmail.com?utm_medium\x3demail\x26utm_source\x3dfooter';return t=
rue;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposal=
s/CAANG%<wbr>3DkWx4WLqCS4MntUjvoLpmyiTZAfBA<wbr>wgrxLbb1dcZiYP9fw%40mail.<w=
br>gmail.com?utm_medium=3Demail&<wbr>utm_source=3Dfooter</a>>.<br>
<br>
-- <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"=
RMMoARgFAwAJ" 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"RMMoARgFAwAJ" 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/eb224183-9d37-8fe4-4dbc-e58c5e01bbce%=
40gmail.com" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D=
'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb224183-=
9d37-8fe4-4dbc-e58c5e01bbce%40gmail.com';return true;" onclick=3D"this.=
href=3D'https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/eb=
224183-9d37-8fe4-4dbc-e58c5e01bbce%40gmail.com';return true;">https://g=
roups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/eb224183-9d37=
-8fe4-<wbr>4dbc-e58c5e01bbce%40gmail.com</a>.<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/26556543-6a2b-4c19-81e7-3144fd502d72%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/26556543-6a2b-4c19-81e7-3144fd502d72=
%40isocpp.org</a>.<br />
------=_Part_7887_1020400717.1532220313231--
------=_Part_7886_778747037.1532220313230--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Sat, 21 Jul 2018 17:47:09 -0700 (PDT)
Raw View
------=_Part_7440_1589289152.1532220429338
Content-Type: multipart/alternative;
boundary="----=_Part_7441_962198391.1532220429338"
------=_Part_7441_962198391.1532220429338
Content-Type: text/plain; charset="UTF-8"
>
>
> Now granted, the point made here about deprecating `std::list` still
> applies; this `plf::list` does *not* supercede `std::list`'s
> functionality (since it is not compatible with `std::list`'s requirements),
> so deprecating it would be inappropriate.
>
>
I won't repeat my question, but your answer doesn't seem to address it.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d3b0bb57-0130-4ee5-b891-88922bc3dd22%40isocpp.org.
------=_Part_7441_962198391.1532220429338
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><div>Now granted, the point made here about deprecating `std::list`=
still applies; this `plf::list` does <i>not</i> supercede `std::list`'=
s functionality (since it is not compatible with `std::list`'s requirem=
ents), so deprecating it would be inappropriate.<br></div><div><br></div></=
div></blockquote><div><br></div><div>I won't repeat my question, but yo=
ur answer doesn't seem to address it.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/d3b0bb57-0130-4ee5-b891-88922bc3dd22%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d3b0bb57-0130-4ee5-b891-88922bc3dd22=
%40isocpp.org</a>.<br />
------=_Part_7441_962198391.1532220429338--
------=_Part_7440_1589289152.1532220429338--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 21 Jul 2018 18:37:34 -0700 (PDT)
Raw View
------=_Part_7454_1040518026.1532223454441
Content-Type: multipart/alternative;
boundary="----=_Part_7455_1896605853.1532223454442"
------=_Part_7455_1896605853.1532223454442
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 21, 2018 at 8:47:09 PM UTC-4, Matthew Bentley wrote:
>
>
>> Now granted, the point made here about deprecating `std::list` still
>> applies; this `plf::list` does *not* supercede `std::list`'s
>> functionality (since it is not compatible with `std::list`'s requirements),
>> so deprecating it would be inappropriate.
>>
>>
> I won't repeat my question, but your answer doesn't seem to address it.
>
I was responding to Ryan; I wasn't really trying to address your question.
But if you want my opinion, it's still right there: deprecating `std::list`
is not appropriate, even if `std::forward_list` might be a viable
replacement in some cases. Splicing is a first-class interface of
`std::list`, and O(1) splice is a first-class feature of the type. You
can't just take that away, even if there's another type that *might* be
usable for a particular user.
Provide your alternative doubly-linked list type and let users decide which
works best for them. But don't mess with choices they've already made.
--
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/f6e0d968-c102-4cc2-a395-106c28a079b3%40isocpp.org.
------=_Part_7455_1896605853.1532223454442
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 21, 2018 at 8:47:09 PM UTC-4, Matthew Be=
ntley wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Now grante=
d, the point made here about deprecating `std::list` still applies; this `p=
lf::list` does <i>not</i> supercede `std::list`'s functionality (since =
it is not compatible with `std::list`'s requirements), so deprecating i=
t would be inappropriate.<br></div><div><br></div></div></blockquote><div><=
br></div><div>I won't repeat my question, but your answer doesn't s=
eem to address it.<br></div></div></blockquote><div><br></div><div>I was re=
sponding to Ryan; I wasn't really trying to address your question.</div=
><div><br></div><div>But if you want my opinion, it's still right there=
: deprecating `std::list` is not appropriate, even if `std::forward_list` m=
ight be a viable replacement in some cases. Splicing is a first-class inter=
face of `std::list`, and O(1) splice is a first-class feature of the type. =
You can't just take that away, even if there's another type that <i=
>might</i> be usable for a particular user.</div><div><br></div><div>Provid=
e your alternative doubly-linked list type and let users decide which works=
best for them. But don't mess with choices they've already made.<b=
r></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/f6e0d968-c102-4cc2-a395-106c28a079b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6e0d968-c102-4cc2-a395-106c28a079b3=
%40isocpp.org</a>.<br />
------=_Part_7455_1896605853.1532223454442--
------=_Part_7454_1040518026.1532223454441--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Sun, 22 Jul 2018 01:34:29 -0700 (PDT)
Raw View
------=_Part_7588_664193839.1532248469744
Content-Type: multipart/alternative;
boundary="----=_Part_7589_2117919919.1532248469744"
------=_Part_7589_2117919919.1532248469744
Content-Type: text/plain; charset="UTF-8"
I'm not "messing" with anything.
I was making a gentle query as to what people preferred. Saying "not
appropriate" isn't useful - saying why, might be.
I'll take your opinion into account, but that question wasn't actually
directed at you.
--
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/3a114b1e-3bfb-43cc-8f89-7052023ff45a%40isocpp.org.
------=_Part_7589_2117919919.1532248469744
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I'm not "messing" with anything.</div><=
div>I was making a gentle query as to what people preferred. Saying "n=
ot appropriate" isn't useful - saying why, might be.</div>I'll=
take your opinion into account, but that question wasn't actually dire=
cted at you.<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/3a114b1e-3bfb-43cc-8f89-7052023ff45a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a114b1e-3bfb-43cc-8f89-7052023ff45a=
%40isocpp.org</a>.<br />
------=_Part_7589_2117919919.1532248469744--
------=_Part_7588_664193839.1532248469744--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 22 Jul 2018 07:44:45 -0700 (PDT)
Raw View
------=_Part_7571_1670990335.1532270685631
Content-Type: multipart/alternative;
boundary="----=_Part_7572_1346754383.1532270685631"
------=_Part_7572_1346754383.1532270685631
Content-Type: text/plain; charset="UTF-8"
On Sunday, July 22, 2018 at 4:34:29 AM UTC-4, Matthew Bentley wrote:
>
> I'm not "messing" with anything.
> I was making a gentle query as to what people preferred. Saying "not
> appropriate" isn't useful - saying why, might be.
>
I thought I explained why: because users are relying that functionality.
When something is standardized, it's like making a promise. The standard
promises that X is available, and thus users can rely on that promise.
If you *change* X, you are reneging on that promise. Reneging on a promise
is generally inappropriate. At the very least, you have to come up with a
convincing reason why you need to abandon that promise.
Consider `std::bind1st/2nd`. These are simple tools that work. However,
they're not being kept around. They're not being kept up-to-date with more
C++ technology. Do we want to spend time conceptualizing them? Updating
them with new functionality as new features emerge? Or should they hang
around forever as some relic of a by-gone age?
Furthermore, `std::bind` is better in every respect than
`std::bind1st/2nd`. It can do everything those types can and more. It's not
quite a drop-in replacement, but there is pretty much no scenario where the
latter is superior to the former.
By contrast, `std::list` is a perfectly functional type; there is nothing
really *wrong* with it. There may be better bidirectional linked list
implementations for some use cases, but `std::list` genuinely offers
functionality that your implementation *cannot*. So long as that is the
case, it is inappropriate to tell people to switch to `std::forward_list`
if they want fast splicing.
Let me put it another way. The flat ordered containers are going to have
much higher performance in many cases than `std::map`. Yet nobody is
suggesting that we deprecate `std::map` just because there's something
that's better in many cases.
You don't throw something away that people are using unless you have
something that is absolutely, undeniably better in *every circumstance*.
--
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/d59014f1-43be-462c-8d92-7830a30309ad%40isocpp.org.
------=_Part_7572_1346754383.1532270685631
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, July 22, 2018 at 4:34:29 AM UTC-4, Matthew Bent=
ley wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>I'm not "messing" with anything.</div><div>I was making a g=
entle query as to what people preferred. Saying "not appropriate"=
isn't useful - saying why, might be.</div></div></blockquote><div><br>=
</div><div>I thought I explained why: because users are relying that functi=
onality.</div><div><br></div><div>When something is standardized, it's =
like making a promise. The standard promises that X is available, and thus =
users can rely on that promise.</div><div><br></div><div>If you <i>change</=
i> X, you are reneging on that promise. Reneging on a promise is generally =
inappropriate. At the very least, you have to come up with a convincing rea=
son why you need to abandon that promise.</div><div><br></div><div>Consider=
`std::bind1st/2nd`. These are simple tools that work. However, they're=
not being kept around. They're not being kept up-to-date with more C++=
technology. Do we want to spend time conceptualizing them? Updating them w=
ith new functionality as new features emerge? Or should they hang around fo=
rever as some relic of a by-gone age?</div><div><br></div><div>Furthermore,=
`std::bind` is better in every respect than `std::bind1st/2nd`. It can do =
everything those types can and more. It's not quite a drop-in replaceme=
nt, but there is pretty much no scenario where the latter is superior to th=
e former.<br></div><div><br></div><div>By contrast, `std::list` is a perfec=
tly functional type; there is nothing really <i>wrong</i> with it. There ma=
y be better bidirectional linked list implementations for some use cases, b=
ut `std::list` genuinely offers functionality that your implementation <i>c=
annot</i>. So long as that is the case, it is inappropriate to tell people =
to switch to `std::forward_list` if they want fast splicing.</div><div><br>=
</div><div>Let me put it another way. The flat ordered containers are going=
to have much higher performance in many cases than `std::map`. Yet nobody =
is suggesting that we deprecate `std::map` just because there's somethi=
ng that's better in many cases.<br></div><div><br></div><div>You don=
9;t throw something away that people are using unless you have something th=
at is absolutely, undeniably better in <i>every circumstance</i>.</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/d59014f1-43be-462c-8d92-7830a30309ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d59014f1-43be-462c-8d92-7830a30309ad=
%40isocpp.org</a>.<br />
------=_Part_7572_1346754383.1532270685631--
------=_Part_7571_1670990335.1532270685631--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Tue, 24 Jul 2018 15:44:05 -0700 (PDT)
Raw View
------=_Part_9438_1301954162.1532472245231
Content-Type: multipart/alternative;
boundary="----=_Part_9439_1597296453.1532472245231"
------=_Part_9439_1597296453.1532472245231
Content-Type: text/plain; charset="UTF-8"
Perhaps this is a miscommunication: the reason why I suggested it's better
not to use words like 'inappropriate', is because it gives an impression of
moral tone which is, I think, counterproductive. It's just code - there's
no reason to get absolutist about it. That subjectivity aside, I get that
there is a non-overlapping area of std::forward_list and plf::list which
std::list covers, but it's a small area, so my question was how important
that is.
To explain further, the goal wasn't to promote my implementation or to have
that be the defacto standard for Any kind of list. It was an
acknowledgement that you get serious performance enhancement opportunities
when you remove ranged (partial) splicing and relax some time complexity
requirements, for std::list. You can't get those opportunities without
doing so, at least on a modern processor. Hopefully there is an
implementation that can perform better than my implementation even.
The non-overlapping area in question is when bidirectional (as opposed to
just forward) iteration is required AND
(a) range-based splicing is needed or
(b) the multithreaded benefits of an insert/erase with fewer side-effects
are desirable.
On Monday, July 23, 2018 at 2:44:45 AM UTC+12, Nicol Bolas wrote:
>
> On Sunday, July 22, 2018 at 4:34:29 AM UTC-4, Matthew Bentley wrote:
>>
>> I'm not "messing" with anything.
>> I was making a gentle query as to what people preferred. Saying "not
>> appropriate" isn't useful - saying why, might be.
>>
>
> I thought I explained why: because users are relying that functionality.
>
> When something is standardized, it's like making a promise. The standard
> promises that X is available, and thus users can rely on that promise.
>
> If you *change* X, you are reneging on that promise. Reneging on a
> promise is generally inappropriate. At the very least, you have to come up
> with a convincing reason why you need to abandon that promise.
>
> Consider `std::bind1st/2nd`. These are simple tools that work. However,
> they're not being kept around. They're not being kept up-to-date with more
> C++ technology. Do we want to spend time conceptualizing them? Updating
> them with new functionality as new features emerge? Or should they hang
> around forever as some relic of a by-gone age?
>
> Furthermore, `std::bind` is better in every respect than
> `std::bind1st/2nd`. It can do everything those types can and more. It's not
> quite a drop-in replacement, but there is pretty much no scenario where the
> latter is superior to the former.
>
> By contrast, `std::list` is a perfectly functional type; there is nothing
> really *wrong* with it. There may be better bidirectional linked list
> implementations for some use cases, but `std::list` genuinely offers
> functionality that your implementation *cannot*. So long as that is the
> case, it is inappropriate to tell people to switch to `std::forward_list`
> if they want fast splicing.
>
> Let me put it another way. The flat ordered containers are going to have
> much higher performance in many cases than `std::map`. Yet nobody is
> suggesting that we deprecate `std::map` just because there's something
> that's better in many cases.
>
> You don't throw something away that people are using unless you have
> something that is absolutely, undeniably better in *every circumstance*.
>
>
--
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/c36011e8-5184-4ef2-8fbf-60abdf9e5105%40isocpp.org.
------=_Part_9439_1597296453.1532472245231
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Perhaps this is a miscommunication: the reason why I =
suggested it's better not to use words like 'inappropriate', is=
because it gives an impression of moral tone which is, I think, counterpro=
ductive. It's just code - there's no reason to get absolutist about=
it. That subjectivity aside, I get that there is a non-overlapping area of=
std::forward_list and plf::list which std::list covers, but it's a sma=
ll area, so my question was how important that is.</div><div><br></div><div=
>To explain further, the goal wasn't to promote my implementation or to=
have that be the defacto standard for Any kind of list. It was an acknowle=
dgement that you get serious performance enhancement opportunities when you=
remove ranged (partial) splicing and relax some time complexity requiremen=
ts, for std::list. You can't get those opportunities without doing so, =
at least on a modern processor. Hopefully there is an implementation that c=
an perform better than my implementation even.<br></div><div>The non-overla=
pping area in question is when bidirectional (as opposed to just forward) i=
teration is required AND</div><div>(a) range-based splicing is needed or</d=
iv><div>(b) the multithreaded benefits of an insert/erase with fewer side-e=
ffects are desirable.</div><div><br></div><br>On Monday, July 23, 2018 at 2=
:44:45 AM UTC+12, 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 Sunday, July 22, 2018 at 4:34:29 AM UTC-4, Matthe=
w Bentley 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"><d=
iv>I'm not "messing" with anything.</div><div>I was making a =
gentle query as to what people preferred. Saying "not appropriate"=
; isn't useful - saying why, might be.</div></div></blockquote><div><br=
></div><div>I thought I explained why: because users are relying that funct=
ionality.</div><div><br></div><div>When something is standardized, it's=
like making a promise. The standard promises that X is available, and thus=
users can rely on that promise.</div><div><br></div><div>If you <i>change<=
/i> X, you are reneging on that promise. Reneging on a promise is generally=
inappropriate. At the very least, you have to come up with a convincing re=
ason why you need to abandon that promise.</div><div><br></div><div>Conside=
r `std::bind1st/2nd`. These are simple tools that work. However, they'r=
e not being kept around. They're not being kept up-to-date with more C+=
+ technology. Do we want to spend time conceptualizing them? Updating them =
with new functionality as new features emerge? Or should they hang around f=
orever as some relic of a by-gone age?</div><div><br></div><div>Furthermore=
, `std::bind` is better in every respect than `std::bind1st/2nd`. It can do=
everything those types can and more. It's not quite a drop-in replacem=
ent, but there is pretty much no scenario where the latter is superior to t=
he former.<br></div><div><br></div><div>By contrast, `std::list` is a perfe=
ctly functional type; there is nothing really <i>wrong</i> with it. There m=
ay be better bidirectional linked list implementations for some use cases, =
but `std::list` genuinely offers functionality that your implementation <i>=
cannot</i>. So long as that is the case, it is inappropriate to tell people=
to switch to `std::forward_list` if they want fast splicing.</div><div><br=
></div><div>Let me put it another way. The flat ordered containers are goin=
g to have much higher performance in many cases than `std::map`. Yet nobody=
is suggesting that we deprecate `std::map` just because there's someth=
ing that's better in many cases.<br></div><div><br></div><div>You don&#=
39;t throw something away that people are using unless you have something t=
hat is absolutely, undeniably better in <i>every circumstance</i>.</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/c36011e8-5184-4ef2-8fbf-60abdf9e5105%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c36011e8-5184-4ef2-8fbf-60abdf9e5105=
%40isocpp.org</a>.<br />
------=_Part_9439_1597296453.1532472245231--
------=_Part_9438_1301954162.1532472245231--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 24 Jul 2018 17:58:00 -0700 (PDT)
Raw View
------=_Part_9160_1590287669.1532480280777
Content-Type: multipart/alternative;
boundary="----=_Part_9161_1456582396.1532480280777"
------=_Part_9161_1456582396.1532480280777
Content-Type: text/plain; charset="UTF-8"
On Tuesday, July 24, 2018 at 6:44:05 PM UTC-4, Matthew Bentley wrote:
>
> Perhaps this is a miscommunication: the reason why I suggested it's better
> not to use words like 'inappropriate', is because it gives an impression of
> moral tone which is, I think, counterproductive. It's just code - there's
> no reason to get absolutist about it.
>
But it is at least partially a moral question. After all, there is no
*technical* reason to change `std::list`. If the committee wants an
improved list type that cannot be a drop-in replacement without breaking
code, they can provide one while keeping the other available. Everyone wins.
So the question of whether it's OK to make backwards-incompatible changes
to `std::list` or to deprecate it has a moral component to it. Is it right
to take a tool someone is using and either tell them to replace it with
something else or make it useless to them?
Consider `auto_ptr`. It was a type that users could use perfectly fine...
so long as they followed the rules. But because it was easy to accidentally
not follow the rules, people would accidentally write broken code. This
made it reasonable to not just provide `unique_ptr`, but to also deprecate
the easily-misused alternative.
That's simply not the case here. Using `std::list` in cases where your
`plf::list` would be viable will never be a *correctness* problem; it will
only ever be a performance issue. And while that's not unimportant,
deprecating a type just because you have something faster seems... rude.
After all, people often use linked lists in use cases when a `vector` would
probably be faster. The possibility of lower-performance misuse does not
stop us from providing linked list types.
That subjectivity aside, I get that there is a non-overlapping area of
> std::forward_list and plf::list which std::list covers, but it's a small
> area, so my question was how important that is.
>
It is not incumbent upon users of `std::list` to justify why it should not
be changed; it is incumbent upon those wanting to change/deprecate it to
explain why it should be changed/deprecated.
You're placing the burden of proof on the wrong party.
To explain further, the goal wasn't to promote my implementation or to have
> that be the defacto standard for Any kind of list. It was an
> acknowledgement that you get serious performance enhancement opportunities
> when you remove ranged (partial) splicing and relax some time complexity
> requirements, for std::list.
>
I don't understand why such acknowledgement requires a discussion involving
the replacement of `std::list` or deprecating it. Has there been some
argument that the "performance enhancement opportunities" you speak of
don't exist?
You can't get those opportunities without doing so, at least on a modern
> processor. Hopefully there is an implementation that can perform better
> than my implementation even.
> The non-overlapping area in question is when bidirectional (as opposed to
> just forward) iteration is required AND
> (a) range-based splicing is needed or
> (b) the multithreaded benefits of an insert/erase with fewer side-effects
> are desirable.
>
>
--
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/5cb2cff6-c23c-456c-87f5-138d361b22f1%40isocpp.org.
------=_Part_9161_1456582396.1532480280777
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, July 24, 2018 at 6:44:05 PM UTC-4, Matthew Ben=
tley 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"><d=
iv>Perhaps this is a miscommunication: the reason why I suggested it's =
better not to use words like 'inappropriate', is because it gives a=
n impression of moral tone which is, I think, counterproductive. It's j=
ust code - there's no reason to get absolutist about it.</div></div></b=
lockquote><div><br></div><div>But it is at least partially a moral question=
.. After all, there is no <i>technical</i> reason to change `std::list`. If =
the committee wants an improved list type that cannot be a drop-in replacem=
ent without breaking code, they can provide one while keeping the other ava=
ilable. Everyone wins.<br></div><div><br></div><div>So the question of whet=
her it's OK to make backwards-incompatible changes to `std::list` or to=
deprecate it has a moral component to it. Is it right to take a tool someo=
ne is using and either tell them to replace it with something else or make =
it useless to them?</div><div><br></div><div>Consider `auto_ptr`. It was a =
type that users could use perfectly fine... so long as they followed the ru=
les. But because it was easy to accidentally not follow the rules, people w=
ould accidentally write broken code. This made it reasonable to not just pr=
ovide `unique_ptr`, but to also deprecate the easily-misused alternative.</=
div><div><br></div><div>That's simply not the case here. Using `std::li=
st` in cases where your `plf::list` would be viable will never be a <i>corr=
ectness</i> problem; it will only ever be a performance issue. And while th=
at's not unimportant, deprecating a type just because you have somethin=
g faster seems... rude. After all, people often use linked lists in use cas=
es when a `vector` would probably be faster. The possibility of lower-perfo=
rmance misuse does not stop us from providing linked list types.<br></div><=
div></div><div><br></div><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div>That subjectivity aside, I get that there is a =
non-overlapping area of std::forward_list and plf::list which std::list cov=
ers, but it's a small area, so my question was how important that is.</=
div></div></blockquote><div><br></div><div>It is not incumbent upon users o=
f `std::list` to justify why it should not be changed; it is incumbent upon=
those wanting to change/deprecate it to explain why it should be changed/d=
eprecated.</div><div><br></div><div>You're placing the burden of proof =
on the wrong party.<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div></div><div>To explain further, the goal=
wasn't to promote my implementation or to have that be the defacto sta=
ndard for Any kind of list. It was an acknowledgement that you get serious =
performance enhancement opportunities when you remove ranged (partial) spli=
cing and relax some time complexity requirements, for std::list.</div></div=
></blockquote><div><br></div><div>I don't understand why such acknowled=
gement requires a discussion involving the replacement of `std::list` or de=
precating it. Has there been some argument that the "performance enhan=
cement opportunities" you speak of don't exist?<br></div><div><br>=
</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>Yo=
u can't get those opportunities without doing so, at least on a modern =
processor. Hopefully there is an implementation that can perform better tha=
n my implementation even.<br></div><div>The non-overlapping area in questio=
n is when bidirectional (as opposed to just forward) iteration is required =
AND</div><div>(a) range-based splicing is needed or</div><div>(b) the multi=
threaded benefits of an insert/erase with fewer side-effects are desirable.=
</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/5cb2cff6-c23c-456c-87f5-138d361b22f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cb2cff6-c23c-456c-87f5-138d361b22f1=
%40isocpp.org</a>.<br />
------=_Part_9161_1456582396.1532480280777--
------=_Part_9160_1590287669.1532480280777--
.
Author: Matthew Bentley <mattreecebentley@gmail.com>
Date: Mon, 20 Aug 2018 13:30:41 +1200
Raw View
--000000000000ea3a880573d3dd38
Content-Type: text/plain; charset="UTF-8"
Only just found this in my spam folder, for some reason.
It's not a moral problem, only a pragmatic one.
The rest of your speech there is similarly hostile. You're reading me
incorrectly, on purpose, to win some argument in your head that I'm not
involved in - and won't be involved in.
Like I said: I was enquiring as to what people thought. That's not the same
as making an argument for something.
Goodbye,
On 25 July 2018 at 12:58, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Tuesday, July 24, 2018 at 6:44:05 PM UTC-4, Matthew Bentley wrote:
>>
>> Perhaps this is a miscommunication: the reason why I suggested it's
>> better not to use words like 'inappropriate', is because it gives an
>> impression of moral tone which is, I think, counterproductive. It's just
>> code - there's no reason to get absolutist about it.
>>
>
> But it is at least partially a moral question. After all, there is no
> *technical* reason to change `std::list`. If the committee wants an
> improved list type that cannot be a drop-in replacement without breaking
> code, they can provide one while keeping the other available. Everyone wins.
>
> So the question of whether it's OK to make backwards-incompatible changes
> to `std::list` or to deprecate it has a moral component to it. Is it right
> to take a tool someone is using and either tell them to replace it with
> something else or make it useless to them?
>
> Consider `auto_ptr`. It was a type that users could use perfectly fine...
> so long as they followed the rules. But because it was easy to accidentally
> not follow the rules, people would accidentally write broken code. This
> made it reasonable to not just provide `unique_ptr`, but to also deprecate
> the easily-misused alternative.
>
> That's simply not the case here. Using `std::list` in cases where your
> `plf::list` would be viable will never be a *correctness* problem; it
> will only ever be a performance issue. And while that's not unimportant,
> deprecating a type just because you have something faster seems... rude.
> After all, people often use linked lists in use cases when a `vector` would
> probably be faster. The possibility of lower-performance misuse does not
> stop us from providing linked list types.
>
> That subjectivity aside, I get that there is a non-overlapping area of
>> std::forward_list and plf::list which std::list covers, but it's a small
>> area, so my question was how important that is.
>>
>
> It is not incumbent upon users of `std::list` to justify why it should not
> be changed; it is incumbent upon those wanting to change/deprecate it to
> explain why it should be changed/deprecated.
>
> You're placing the burden of proof on the wrong party.
>
> To explain further, the goal wasn't to promote my implementation or to
>> have that be the defacto standard for Any kind of list. It was an
>> acknowledgement that you get serious performance enhancement opportunities
>> when you remove ranged (partial) splicing and relax some time complexity
>> requirements, for std::list.
>>
>
> I don't understand why such acknowledgement requires a discussion
> involving the replacement of `std::list` or deprecating it. Has there been
> some argument that the "performance enhancement opportunities" you speak of
> don't exist?
>
> You can't get those opportunities without doing so, at least on a modern
>> processor. Hopefully there is an implementation that can perform better
>> than my implementation even.
>> The non-overlapping area in question is when bidirectional (as opposed to
>> just forward) iteration is required AND
>> (a) range-based splicing is needed or
>> (b) the multithreaded benefits of an insert/erase with fewer side-effects
>> are desirable.
>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/9AeGHm9oMm0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/5cb2cff6-c23c-456c-
> 87f5-138d361b22f1%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5cb2cff6-c23c-456c-87f5-138d361b22f1%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/CAN%2BCa03v_90oN%3DZbuEafrme%2BbjJr-DYO%3DYmYBcyVfQsrSRT5Rg%40mail.gmail.com.
--000000000000ea3a880573d3dd38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Only just found this in my spam folder, for some reas=
on.</div><div>It's not a moral problem, only a pragmatic one.</div><div=
>The rest of your speech there is similarly hostile. You're reading me =
incorrectly, on purpose, to win some argument in your head that I'm not=
involved in - and won't be involved in.</div><div>Like I said: I was e=
nquiring as to what people thought. That's not the same as making an ar=
gument for something.</div><div>Goodbye,<br></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On 25 July 2018 at 12:58, Nicol Bola=
s <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com" target=3D"_b=
lank">jmckesson@gmail.com</a>></span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><span class=3D"">On Tuesday, July 24, 2018 at 6:44:=
05 PM UTC-4, Matthew Bentley 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>Perhaps this is a miscommunication: the reason why I=
suggested it's better not to use words like 'inappropriate', i=
s because it gives an impression of moral tone which is, I think, counterpr=
oductive. It's just code - there's no reason to get absolutist abou=
t it.</div></div></blockquote><div><br></div></span><div>But it is at least=
partially a moral question. After all, there is no <i>technical</i> reason=
to change `std::list`. If the committee wants an improved list type that c=
annot be a drop-in replacement without breaking code, they can provide one =
while keeping the other available. Everyone wins.<br></div><div><br></div><=
div>So the question of whether it's OK to make backwards-incompatible c=
hanges to `std::list` or to deprecate it has a moral component to it. Is it=
right to take a tool someone is using and either tell them to replace it w=
ith something else or make it useless to them?</div><div><br></div><div>Con=
sider `auto_ptr`. It was a type that users could use perfectly fine... so l=
ong as they followed the rules. But because it was easy to accidentally not=
follow the rules, people would accidentally write broken code. This made i=
t reasonable to not just provide `unique_ptr`, but to also deprecate the ea=
sily-misused alternative.</div><div><br></div><div>That's simply not th=
e case here. Using `std::list` in cases where your `plf::list` would be via=
ble will never be a <i>correctness</i> problem; it will only ever be a perf=
ormance issue. And while that's not unimportant, deprecating a type jus=
t because you have something faster seems... rude. After all, people often =
use linked lists in use cases when a `vector` would probably be faster. The=
possibility of lower-performance misuse does not stop us from providing li=
nked list types.<br></div><span class=3D""><div></div><div><br></div><div><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That sub=
jectivity aside, I get that there is a non-overlapping area of std::forward=
_list and plf::list which std::list covers, but it's a small area, so m=
y question was how important that is.</div></div></blockquote><div><br></di=
v></span><div>It is not incumbent upon users of `std::list` to justify why =
it should not be changed; it is incumbent upon those wanting to change/depr=
ecate it to explain why it should be changed/deprecated.</div><div><br></di=
v><div>You're placing the burden of proof on the wrong party.<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"><di=
v dir=3D"ltr"><div></div><div>To explain further, the goal wasn't to pr=
omote my implementation or to have that be the defacto standard for Any kin=
d of list. It was an acknowledgement that you get serious performance enhan=
cement opportunities when you remove ranged (partial) splicing and relax so=
me time complexity requirements, for std::list.</div></div></blockquote><di=
v><br></div></span><div>I don't understand why such acknowledgement req=
uires a discussion involving the replacement of `std::list` or deprecating =
it. Has there been some argument that the "performance enhancement opp=
ortunities" you speak of don't exist?<br></div><span class=3D""><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>=
You can't get those opportunities without doing so, at least on a moder=
n processor. Hopefully there is an implementation that can perform better t=
han my implementation even.<br></div><div>The non-overlapping area in quest=
ion is when bidirectional (as opposed to just forward) iteration is require=
d AND</div><div>(a) range-based splicing is needed or</div><div>(b) the mul=
tithreaded benefits of an insert/erase with fewer side-effects are desirabl=
e.</div><br></div></blockquote></span></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/9AeGHm9oMm0/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/9=
AeGHm9oMm0/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5cb2cff6-c23c-456c-87f5-138d361b22f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/5cb2=
cff6-c23c-456c-<wbr>87f5-138d361b22f1%40isocpp.org</a><wbr>.<br>
</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/CAN%2BCa03v_90oN%3DZbuEafrme%2BbjJr-D=
YO%3DYmYBcyVfQsrSRT5Rg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAN%2BCa0=
3v_90oN%3DZbuEafrme%2BbjJr-DYO%3DYmYBcyVfQsrSRT5Rg%40mail.gmail.com</a>.<br=
/>
--000000000000ea3a880573d3dd38--
.