<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 10, 2017 at 3:39 PM, C Bergström <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Two points and this my be more philosophy<br>
<br>
#1 Is having the duplicate functionality bad for whoever is a user of<br>
the experimental version? iow is it a disservice to keeping it for any<br>
period of time? If so why would anyone advocate anything except<br>
immediate deprecation or removal?<br></blockquote><div><br></div><div>Because people who have code bases that use std::experimental::string_view (for example) shouldn't have the rug yanked out from under them w/o any notice. We want to encourage people to use these features, and give us feedback (and besides, they're supposed to be useful).</div><div><br></div><div>With this policy (and announcement) we will put people on notice that these capabilities have been superseded by newer versions (in namespace std), and giving them a period of time (two releases) to move their code over to use the new versions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
#2 How did this happen and why didn't anyone notice? (Apologies if<br>
putting anyone on the spot and not my intention) Does it raise<br>
questions about how the experimental namespace and stuff should be<br>
managed.<br></blockquote><div><br></div><div>Oh, we all noticed.</div><div><br></div><div>The Library Fundamentals TS (LFTS) introduced std::experimental::any/string_view/optional back about 2014. People implemented them and other people used them. :-)   We got feedback from users and implementers on how they could be improved.</div><div><br></div><div>In 2016, the standards committee voted to include these (updated) bits from the TS into C++17.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think less overhead will encourage innovation on experimental stuff.<br>
When /you/ start adding maintenance burdens or guarantees, especially<br>
for code which *you* aren't the maintainer it becomes unfun.<br></blockquote><div><br></div><div>Right - which is why I'm proposing to get rid of the 'experimental' versions once we have the 'final' (non-experimental) ones.</div><div><br></div><div>-- Marshall</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On Tue, Apr 11, 2017 at 6:27 AM, Christopher Di Bella via cfe-dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> I second Justin's suggestion, but would that happen in LLVM 5 or 6?<br>
><br>
> Just as something to consider, it may also cause spurious errors for people<br>
> who are relying on the at-version-stability of experimental libraries,<br>
> causing them to turn off warnings for deprecated code.<br>
><br>
> As C Bergstrom has said, users buy into experimental libraries with the<br>
> knowledge that the interface or behaviour could change at a moment's notice,<br>
> so it might not be an issue, but it is worth considering.<br>
><br>
><br>
> On Tue., 11 Apr. 2017, 08:11 Justin Bogner via cfe-dev,<br>
> <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Marshall Clow via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> writes:<br>
>> > As part of the work on C++17, WG21 released a series of "Technical<br>
>> > Specifications", (TS) which added proposed new features to the standard<br>
>> > library. These were all defined in the namespace 'std::experimental'<br>
>> > (and<br>
>> > namespaces inside of that).<br>
>> ><br>
>> > Then, much of these features were merged into the main standard, and<br>
>> > became<br>
>> > part of namespace 'std'.  Libc++ now has two implementations of several<br>
>> > of<br>
>> > these, and they are diverging (because changes were made to the ones in<br>
>> > the<br>
>> > main standard, but not to the ones in the TS.<br>
>> ><br>
>> > In the long run, I would like to remove the TS versions of these<br>
>> > features<br>
>> > from libc++ - since there are "better" versions in the main standard<br>
>> > now.<br>
>> > However, since people are using these, I don't think yanking them w/o<br>
>> > warning is the right thing to do.<br>
>> ><br>
>> > So, I'm proposing a new policy, and a timetable:<br>
>> ><br>
>> > One year.<br>
>> ><br>
>> > One year after we ship a LLVM release that supports a new C++ standard,<br>
>> > we<br>
>> > will remove all the features that are in the 'experimental' namespace<br>
>> > that<br>
>> > are implemented in the new standard).<br>
>> ><br>
>> > Applying this policy to C++17,  we get:<br>
>> ><br>
>> > LLVM 5.0 will support C++17.<br>
>> ><br>
>> > So, for LLVM 7.0, we will remove (at least) the following features from<br>
>> > libc++<br>
>> > * std::experimental::filesystem<br>
>> > * std::experimental::optional<br>
>> > * std::experimental::any<br>
>> > * std::experimental::string_view<br>
>> > * the searchers (std::experimental::boyer_<wbr>moore, etc)<br>
>> > * std::experimental::random_<wbr>shuffle<br>
>><br>
>> Should we throw [[deprecated("use std::filesystem")]] and such on these<br>
>> things in the window between the non-experimental version being released<br>
>> and the experimental one being removed?<br>
>><br>
>> > and probably other things...<br>
>> ><br>
>> > Comments?<br>
>> ><br>
>> > -- Marshall<br>
>> > ______________________________<wbr>_________________<br>
>> > cfe-dev mailing list<br>
>> > <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
>> ______________________________<wbr>_________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
><br>
</div></div></blockquote></div><br></div></div>