llvm dev - Apr 2017 - [cfe-dev] RFC: Plan for removing components from namespace std::experimental

I second Justin's suggestion, but would that happen in LLVM 5 or 6?

Just as something to consider, it may also cause spurious errors for people
who are relying on the at-version-stability of experimental libraries,
causing them to turn off warnings for deprecated code.

As C Bergstrom has said, users buy into experimental libraries with the
knowledge that the interface or behaviour could change at a moment's
notice, so it might not be an issue, but it is worth considering.

On Tue., 11 Apr. 2017, 08:11 Justin Bogner via cfe-dev, <
cfe-dev at lists.llvm.org> wrote:
> Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> writes:
> > As part of the work on C++17, WG21 released a series of
"Technical
> > Specifications", (TS) which added proposed new features to the
standard
> > library. These were all defined in the namespace
'std::experimental' (and
> > namespaces inside of that).
> >
> > Then, much of these features were merged into the main standard, and
> became
> > part of namespace 'std'.  Libc++ now has two implementations
of several
> of
> > these, and they are diverging (because changes were made to the ones
in
> the
> > main standard, but not to the ones in the TS.
> >
> > In the long run, I would like to remove the TS versions of these
features
> > from libc++ - since there are "better" versions in the main
standard now.
> > However, since people are using these, I don't think yanking them
w/o
> > warning is the right thing to do.
> >
> > So, I'm proposing a new policy, and a timetable:
> >
> > One year.
> >
> > One year after we ship a LLVM release that supports a new C++
standard,
> we
> > will remove all the features that are in the 'experimental'
namespace
> that
> > are implemented in the new standard).
> >
> > Applying this policy to C++17,  we get:
> >
> > LLVM 5.0 will support C++17.
> >
> > So, for LLVM 7.0, we will remove (at least) the following features
from
> > libc++
> > * std::experimental::filesystem
> > * std::experimental::optional
> > * std::experimental::any
> > * std::experimental::string_view
> > * the searchers (std::experimental::boyer_moore, etc)
> > * std::experimental::random_shuffle
>
> Should we throw [[deprecated("use std::filesystem")]] and such on
these
> things in the window between the non-experimental version being released
> and the experimental one being removed?
>
> > and probably other things...
> >
> > Comments?
> >
> > -- Marshall
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170410/831a08c1/attachment.html>

Two points and this my be more philosophy

#1 Is having the duplicate functionality bad for whoever is a user of
the experimental version? iow is it a disservice to keeping it for any
period of time? If so why would anyone advocate anything except
immediate deprecation or removal?

#2 How did this happen and why didn't anyone notice? (Apologies if
putting anyone on the spot and not my intention) Does it raise
questions about how the experimental namespace and stuff should be
managed.

I think less overhead will encourage innovation on experimental stuff.
When /you/ start adding maintenance burdens or guarantees, especially
for code which *you* aren't the maintainer it becomes unfun.




On Tue, Apr 11, 2017 at 6:27 AM, Christopher Di Bella via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> I second Justin's suggestion, but would that happen in LLVM 5 or 6?
>
> Just as something to consider, it may also cause spurious errors for people
> who are relying on the at-version-stability of experimental libraries,
> causing them to turn off warnings for deprecated code.
>
> As C Bergstrom has said, users buy into experimental libraries with the
> knowledge that the interface or behaviour could change at a moment's
notice,
> so it might not be an issue, but it is worth considering.
>
>
> On Tue., 11 Apr. 2017, 08:11 Justin Bogner via cfe-dev,
> <cfe-dev at lists.llvm.org> wrote:
>>
>> Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org> writes:
>> > As part of the work on C++17, WG21 released a series of
"Technical
>> > Specifications", (TS) which added proposed new features to
the standard
>> > library. These were all defined in the namespace
'std::experimental'
>> > (and
>> > namespaces inside of that).
>> >
>> > Then, much of these features were merged into the main standard,
and
>> > became
>> > part of namespace 'std'.  Libc++ now has two
implementations of several
>> > of
>> > these, and they are diverging (because changes were made to the
ones in
>> > the
>> > main standard, but not to the ones in the TS.
>> >
>> > In the long run, I would like to remove the TS versions of these
>> > features
>> > from libc++ - since there are "better" versions in the
main standard
>> > now.
>> > However, since people are using these, I don't think yanking
them w/o
>> > warning is the right thing to do.
>> >
>> > So, I'm proposing a new policy, and a timetable:
>> >
>> > One year.
>> >
>> > One year after we ship a LLVM release that supports a new C++
standard,
>> > we
>> > will remove all the features that are in the
'experimental' namespace
>> > that
>> > are implemented in the new standard).
>> >
>> > Applying this policy to C++17,  we get:
>> >
>> > LLVM 5.0 will support C++17.
>> >
>> > So, for LLVM 7.0, we will remove (at least) the following features
from
>> > libc++
>> > * std::experimental::filesystem
>> > * std::experimental::optional
>> > * std::experimental::any
>> > * std::experimental::string_view
>> > * the searchers (std::experimental::boyer_moore, etc)
>> > * std::experimental::random_shuffle
>>
>> Should we throw [[deprecated("use std::filesystem")]] and
such on these
>> things in the window between the non-experimental version being
released
>> and the experimental one being removed?
>>
>> > and probably other things...
>> >
>> > Comments?
>> >
>> > -- Marshall
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

On Mon, Apr 10, 2017 at 3:39 PM, C Bergström <cbergstrom at pathscale.com>
wrote:
> Two points and this my be more philosophy
>
> #1 Is having the duplicate functionality bad for whoever is a user of
> the experimental version? iow is it a disservice to keeping it for any
> period of time? If so why would anyone advocate anything except
> immediate deprecation or removal?
>
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).

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.

>
> #2 How did this happen and why didn't anyone notice? (Apologies if
> putting anyone on the spot and not my intention) Does it raise
> questions about how the experimental namespace and stuff should be
> managed.
>
Oh, we all noticed.

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.

In 2016, the standards committee voted to include these (updated) bits from
the TS into C++17.

I think less overhead will encourage innovation on experimental
stuff.
> When /you/ start adding maintenance burdens or guarantees, especially
> for code which *you* aren't the maintainer it becomes unfun.
>
Right - which is why I'm proposing to get rid of the 'experimental'
versions once we have the 'final' (non-experimental) ones.

-- Marshall


>
>
>
>
> On Tue, Apr 11, 2017 at 6:27 AM, Christopher Di Bella via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > I second Justin's suggestion, but would that happen in LLVM 5 or
6?
> >
> > Just as something to consider, it may also cause spurious errors for
> people
> > who are relying on the at-version-stability of experimental libraries,
> > causing them to turn off warnings for deprecated code.
> >
> > As C Bergstrom has said, users buy into experimental libraries with
the
> > knowledge that the interface or behaviour could change at a
moment's
> notice,
> > so it might not be an issue, but it is worth considering.
> >
> >
> > On Tue., 11 Apr. 2017, 08:11 Justin Bogner via cfe-dev,
> > <cfe-dev at lists.llvm.org> wrote:
> >>
> >> Marshall Clow via cfe-dev <cfe-dev at lists.llvm.org>
writes:
> >> > As part of the work on C++17, WG21 released a series of
"Technical
> >> > Specifications", (TS) which added proposed new features
to the
> standard
> >> > library. These were all defined in the namespace
'std::experimental'
> >> > (and
> >> > namespaces inside of that).
> >> >
> >> > Then, much of these features were merged into the main
standard, and
> >> > became
> >> > part of namespace 'std'.  Libc++ now has two
implementations of
> several
> >> > of
> >> > these, and they are diverging (because changes were made to
the ones
> in
> >> > the
> >> > main standard, but not to the ones in the TS.
> >> >
> >> > In the long run, I would like to remove the TS versions of
these
> >> > features
> >> > from libc++ - since there are "better" versions in
the main standard
> >> > now.
> >> > However, since people are using these, I don't think
yanking them w/o
> >> > warning is the right thing to do.
> >> >
> >> > So, I'm proposing a new policy, and a timetable:
> >> >
> >> > One year.
> >> >
> >> > One year after we ship a LLVM release that supports a new C++
> standard,
> >> > we
> >> > will remove all the features that are in the
'experimental' namespace
> >> > that
> >> > are implemented in the new standard).
> >> >
> >> > Applying this policy to C++17,  we get:
> >> >
> >> > LLVM 5.0 will support C++17.
> >> >
> >> > So, for LLVM 7.0, we will remove (at least) the following
features
> from
> >> > libc++
> >> > * std::experimental::filesystem
> >> > * std::experimental::optional
> >> > * std::experimental::any
> >> > * std::experimental::string_view
> >> > * the searchers (std::experimental::boyer_moore, etc)
> >> > * std::experimental::random_shuffle
> >>
> >> Should we throw [[deprecated("use std::filesystem")]]
and such on these
> >> things in the window between the non-experimental version being
released
> >> and the experimental one being removed?
> >>
> >> > and probably other things...
> >> >
> >> > Comments?
> >> >
> >> > -- Marshall
> >> > _______________________________________________
> >> > cfe-dev mailing list
> >> > cfe-dev at lists.llvm.org
> >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170410/7509278b/attachment-0001.html>