Topic: Removing and deprecating features in the standard
Author: Matthew Fioravante <fmatthew5876@gmail.com>
Date: Wed, 28 Sep 2016 07:20:10 -0700 (PDT)
Raw View
------=_Part_77_1609544013.1475072410478
Content-Type: multipart/alternative;
boundary="----=_Part_78_587278056.1475072410478"
------=_Part_78_587278056.1475072410478
Content-Type: text/plain; charset=UTF-8
Watching some of the cppcon talks, it looks like there is a real desire to
create a version 2 of the STL.
My question is if that is the case, then why should we worry so much about
removing deprecated features like std::auto_ptr and std::bind from the
current standard? Sure these things should be at least discouraged from use
and teaching via deprecation but is it worth spending valuable time and
effort writing proposals and scheduling committee meetings to argue about
removing them outright from the standard? Personally, I think that time
would be better spend adding useful new features or designing version 2 of
the STL.
What do you think?
--
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/08dad487-b1e7-43db-8c94-056207128fdd%40isocpp.org.
------=_Part_78_587278056.1475072410478
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Watching some of the cppcon talks, it looks like there is =
a real desire to create a version 2 of the STL.<div><br></div><div>My quest=
ion is if that is the case, then why should we worry so much about removing=
deprecated features like std::auto_ptr and std::bind from the current stan=
dard? Sure these things should be at least discouraged from use and teachin=
g via deprecation but is it worth spending valuable time and effort writing=
proposals and scheduling committee meetings to argue about removing them o=
utright from the standard? Personally, I think that time would be better sp=
end adding useful new features or designing version 2 of the STL.</div><div=
><br></div><div>What do you think?</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/08dad487-b1e7-43db-8c94-056207128fdd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08dad487-b1e7-43db-8c94-056207128fdd=
%40isocpp.org</a>.<br />
------=_Part_78_587278056.1475072410478--
------=_Part_77_1609544013.1475072410478--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Sep 2016 09:54:20 -0700 (PDT)
Raw View
------=_Part_2038_1714988355.1475081660577
Content-Type: multipart/alternative;
boundary="----=_Part_2039_618527104.1475081660577"
------=_Part_2039_618527104.1475081660577
Content-Type: text/plain; charset=UTF-8
On Wednesday, September 28, 2016 at 10:20:10 AM UTC-4, Matthew Fioravante
wrote:
>
> Watching some of the cppcon talks, it looks like there is a real desire to
> create a version 2 of the STL.
>
> My question is if that is the case, then why should we worry so much about
> removing deprecated features like std::auto_ptr and std::bind from the
> current standard? Sure these things should be at least discouraged from use
> and teaching via deprecation but is it worth spending valuable time and
> effort writing proposals and scheduling committee meetings to argue about
> removing them outright from the standard?
>
Considering that all of the "writing proposals and scheduling committee
meetings" about `auto_ptr` is already done, that's kind of a moot point.
And I don't recall anyone proposing to get rid of `std::bind`.
Furthermore, just because you have an "STL2" doesn't mean we're going to
throw away "STL1". All of that code ought to keep working.
Personally, I think that time would be better spend adding useful new
> features or designing version 2 of the STL.
>
> What do you think?
>
I think any sort of STL2 would be an absolute *nightmare* from a
standardization perspective. Everyone and their mother will come out of the
woodwork with every little feature they want. Every small annoyance, every
pet feature that anyone has ever wanted will be thrown into the pot.
It'll be chaos that drags out for years.
Remember: STL1 happened because there was a single specific idea with a
focused scope developed by a small group. STL2 would have to be
design-by-committee, and that almost never ends well.
If STL2 is going to happen, then I say that any proposals towards that end
should be:
1: Fully formed. Not "here's what I think an array class should look like,
but someone else can propose replacements for `list` and `map`." A full
suite of classes and functions that covers all of the bases of the existing
containers/iterators/algorithms/ranges systems. It can cover other things
too, but it needs to be complete from the start.
2: Have an actual and complete implementation, which works across at least
two compilers.
--
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/a6db0179-0928-4537-9e8f-76260792ae38%40isocpp.org.
------=_Part_2039_618527104.1475081660577
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, September 28, 2016 at 10:20:10 AM UTC-4, Mat=
thew Fioravante 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">Watching some of the cppcon talks, it looks like there is a real d=
esire to create a version 2 of the STL.<div><br></div><div>My question is i=
f that is the case, then why should we worry so much about removing depreca=
ted features like std::auto_ptr and std::bind from the current standard? Su=
re these things should be at least discouraged from use and teaching via de=
precation but is it worth spending valuable time and effort writing proposa=
ls and scheduling committee meetings to argue about removing them outright =
from the standard?</div></div></blockquote><div><br>Considering that all of=
the "writing proposals and scheduling committee meetings" about =
`auto_ptr` is already done, that's kind of a moot point. And I don'=
t recall anyone proposing to get rid of `std::bind`.<br><br>Furthermore, ju=
st because you have an "STL2" doesn't mean we're going to=
throw away "STL1". All of that code ought to keep working.<br><b=
r></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>=
Personally, I think that time would be better spend adding useful new featu=
res or designing version 2 of the STL.</div><div><br></div><div>What do you=
think?</div></div></blockquote><div><br>I think any sort of STL2 would be =
an absolute <i>nightmare</i> from a standardization perspective. Everyone a=
nd their mother will come out of the woodwork with every little feature the=
y want. Every small annoyance, every pet feature that anyone has ever wante=
d will be thrown into the pot.<br><br>It'll be chaos that drags out for=
years.<br><br>Remember: STL1 happened because there was a single specific =
idea with a focused scope developed by a small group. STL2 would have to be=
design-by-committee, and that almost never ends well.<br><br>If STL2 is go=
ing to happen, then I say that any proposals towards that end should be:<br=
><br>1: Fully formed. Not "here's what I think an array class shou=
ld look like, but someone else can propose replacements for `list` and `map=
`." A full suite of classes and functions that covers all of the bases=
of the existing containers/iterators/algorithms/ranges systems. It can cov=
er other things too, but it needs to be complete from the start.<br><br>2: =
Have an actual and complete implementation, which works across at least two=
compilers.<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/a6db0179-0928-4537-9e8f-76260792ae38%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a6db0179-0928-4537-9e8f-76260792ae38=
%40isocpp.org</a>.<br />
------=_Part_2039_618527104.1475081660577--
------=_Part_2038_1714988355.1475081660577--
.
Author: HarD Gamer <rodrigojose690@gmail.com>
Date: Wed, 28 Sep 2016 17:31:39 -0700 (PDT)
Raw View
------=_Part_123_1988139964.1475109099784
Content-Type: multipart/alternative;
boundary="----=_Part_124_229226160.1475109099784"
------=_Part_124_229226160.1475109099784
Content-Type: text/plain; charset=UTF-8
A new STD is needled, with updanting what is older (e.g, stream), adding
what is missing (e.g, sql, cgi ....),
make a new naming convention, and so on...
<https://lh3.googleusercontent.com/-H6S5AJ25eko/V-xg6eW-DKI/AAAAAAAAAQ4/xfC0uoeg0VkzcGcuANt5Sb2jBF_WpkcAQCLcB/s1600/stdcpp.png>
I would like see a code like that (in standard c++)
--
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/52b5092c-8de3-4182-9c4f-5a6d46486078%40isocpp.org.
------=_Part_124_229226160.1475109099784
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><span style=3D"font-family: arial, sans-serif; font-si=
ze: small;">A new STD is needled, with updanting what is older (e.g, stream=
), adding what is missing (e.g, sql, cgi ....),</span><div style=3D"font-fa=
mily: arial, sans-serif; font-size: small;">make a new naming convention, a=
nd so on...</div><p class=3D"separator" style=3D"text-align: center; clear:=
both;"><a imageanchor=3D"1" href=3D"https://lh3.googleusercontent.com/-H6S=
5AJ25eko/V-xg6eW-DKI/AAAAAAAAAQ4/xfC0uoeg0VkzcGcuANt5Sb2jBF_WpkcAQCLcB/s160=
0/stdcpp.png" style=3D"margin-left: 1em; margin-right: 1em;"><img src=3D"ht=
tps://lh3.googleusercontent.com/-H6S5AJ25eko/V-xg6eW-DKI/AAAAAAAAAQ4/xfC0uo=
eg0VkzcGcuANt5Sb2jBF_WpkcAQCLcB/s1600/stdcpp.png" border=3D"0" style=3D""><=
/a></p><div style=3D"font-family: arial, sans-serif; font-size: small;">I w=
ould like see a code like that (in standard c++)</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/52b5092c-8de3-4182-9c4f-5a6d46486078%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/52b5092c-8de3-4182-9c4f-5a6d46486078=
%40isocpp.org</a>.<br />
------=_Part_124_229226160.1475109099784--
------=_Part_123_1988139964.1475109099784--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Sep 2016 18:28:50 -0700 (PDT)
Raw View
------=_Part_36_849686102.1475112530738
Content-Type: multipart/alternative;
boundary="----=_Part_37_1080509627.1475112530738"
------=_Part_37_1080509627.1475112530738
Content-Type: text/plain; charset=UTF-8
The whole STL 2 thing is about making important backwards incompatible
changes to standard library features. It is not about adding "what is
missing". At least, not the kinds of missing things you're talking about.
That's not to say that those aren't important. But there's no reason they
can't be added to the standard library as it currently exists. Whereas
fixing the problems with allocators cannot be done with the containers as
they currently exist. You have to define new containers that work with the
new allocator interfaces.
And you can take naming conventions off the table; that's not gonna happen.
--
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/189f9e1b-e037-4117-ba8e-4d5a86291e8d%40isocpp.org.
------=_Part_37_1080509627.1475112530738
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The whole STL 2 thing is about making important backwards =
incompatible changes to standard library features. It is not about adding &=
quot;what is missing". At least, not the kinds of missing things you&#=
39;re talking about.<br><br>That's not to say that those aren't imp=
ortant. But there's no reason they can't be added to the standard l=
ibrary as it currently exists. Whereas fixing the problems with allocators =
cannot be done with the containers as they currently exist. You have to def=
ine new containers that work with the new allocator interfaces.<br><br>And =
you can take naming conventions off the table; that's not gonna happen.=
</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/189f9e1b-e037-4117-ba8e-4d5a86291e8d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/189f9e1b-e037-4117-ba8e-4d5a86291e8d=
%40isocpp.org</a>.<br />
------=_Part_37_1080509627.1475112530738--
------=_Part_36_849686102.1475112530738--
.
Author: Tomasz <tomaszkam@gmail.com>
Date: Wed, 28 Sep 2016 21:46:18 -0700 (PDT)
Raw View
------=_Part_115_1940849936.1475124378727
Content-Type: multipart/alternative;
boundary="----=_Part_116_426733588.1475124378728"
------=_Part_116_426733588.1475124378728
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
W dniu =C5=9Broda, 28 wrze=C5=9Bnia 2016 18:54:20 UTC+2 u=C5=BCytkownik Nic=
ol Bolas=20
napisa=C5=82:
>
>
> And I don't recall anyone proposing to get rid of `std::bind`.
>
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0356r0.html=20
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7286a366-0fef-47fc-826b-57521ff483ac%40isocpp.or=
g.
------=_Part_116_426733588.1475124378728
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>W dniu =C5=9Broda, 28 wrze=C5=9Bnia 2016 18:54:20 =
UTC+2 u=C5=BCytkownik Nicol Bolas napisa=C5=82:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><br><div>=C2=A0And I don't recall any=
one proposing to get rid of `std::bind`.</div></div></blockquote><div><br>h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0356r0.html <br></d=
iv></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/7286a366-0fef-47fc-826b-57521ff483ac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7286a366-0fef-47fc-826b-57521ff483ac=
%40isocpp.org</a>.<br />
------=_Part_116_426733588.1475124378728--
------=_Part_115_1940849936.1475124378727--
.