Topic: Removing and deprecating features in the
Author: Chris DeVisser <chris.n.devisser@gmail.com>
Date: Wed, 28 Sep 2016 22:02:49 -0400
Raw View
--001a1141f2a61c5627053d9be1f7
Content-Type: text/plain; charset=UTF-8
>
> And I don't recall anyone proposing to get rid of `std::bind`.
STL said informally in a CppCon panel <https://youtu.be/j84pZM840eI?t=1263>
that he would like it "to go away". That isn't a proposal by any means, but
it could be where the notion came from. As he says, he's also brought this
up in the past (perhaps in his 2015 talk).
On Wed, Sep 28, 2016 at 12:54 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> 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
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6db0179-0928-4537-9e8f-76260792ae38%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/CAM6NJy4nubrZDSUrR5tJBmJLGF9tfk%3DRuWNDyRpEhBLDc_AXqg%40mail.gmail.com.
--001a1141f2a61c5627053d9be1f7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span st=
yle=3D"font-size:12.8px">And I don't recall anyone proposing to get rid=
of `std::bind`.</span></blockquote><div><br></div>STL said informally in a=
<a href=3D"https://youtu.be/j84pZM840eI?t=3D1263">CppCon panel</a> that he=
would like it "to go away".=C2=A0That isn't a proposal by an=
y means, but it=C2=A0could be where the notion came from. As he says, he=
9;s also brought this up in the past (perhaps in his 2015 talk).=C2=A0<br><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Sep =
28, 2016 at 12:54 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:j=
mckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On=
Wednesday, September 28, 2016 at 10:20:10 AM UTC-4, Matthew Fioravante wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Watching some o=
f the cppcon talks, it looks like there is a real desire to create a versio=
n 2 of the STL.<div><br></div><div>My question is if that is the case, then=
why should we worry so much about removing deprecated features like std::a=
uto_ptr and std::bind from the current standard? Sure these things should b=
e at least discouraged from use and teaching via deprecation but is it wort=
h spending valuable time and effort writing proposals and scheduling commit=
tee meetings to argue about removing them outright from the standard?</div>=
</div></blockquote></span><div><br>Considering that all of the "writin=
g proposals and scheduling committee meetings" about `auto_ptr` is alr=
eady done, that's kind of a moot point. And I don't recall anyone p=
roposing to get rid of `std::bind`.<br><br>Furthermore, just because you ha=
ve an "STL2" doesn't mean we're going to throw away "=
;STL1". All of that code ought to keep working.<br><br></div><span cla=
ss=3D""><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>Perso=
nally, I think that time would be better spend adding useful new features o=
r designing version 2 of the STL.</div><div><br></div><div>What do you thin=
k?</div></div></blockquote></span><div><br>I think any sort of STL2 would b=
e an absolute <i>nightmare</i> from a standardization perspective. Everyone=
and their mother will come out of the woodwork with every little feature t=
hey want. Every small annoyance, every pet feature that anyone has ever wan=
ted will be thrown into the pot.<br><br>It'll be chaos that drags out f=
or years.<br><br>Remember: STL1 happened because there was a single specifi=
c 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 =
going 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 sh=
ould look like, but someone else can propose replacements for `list` and `m=
ap`." A full suite of classes and functions that covers all of the bas=
es of the existing containers/iterators/<wbr>algorithms/ranges systems. It =
can cover 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 le=
ast two compilers.<br></div></div><span class=3D"">
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a6db0179-0928-4537-9e8f-76260792ae38%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a6db=
0179-0928-4537-<wbr>9e8f-76260792ae38%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/CAM6NJy4nubrZDSUrR5tJBmJLGF9tfk%3DRuW=
NDyRpEhBLDc_AXqg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAM6NJy4nubrZDS=
UrR5tJBmJLGF9tfk%3DRuWNDyRpEhBLDc_AXqg%40mail.gmail.com</a>.<br />
--001a1141f2a61c5627053d9be1f7--
.