Quantcast

RFC: Plan for removing components from namespace std::experimental

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
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

and probably other things...

Comments?

-- Marshall


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
I think regardless of who may or may not be using *experimental* stuff
there shouldn't be a level of guaranteed stability. As the name
implies it's not stable. It's a vehicle for testing things and
prototype implementations that can't make it into main. Show me
another project where experimental == guaranteed stability

On Tue, Apr 11, 2017 at 4:22 AM, Marshall Clow via cfe-dev
<[hidden email]> wrote:

> 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
>
> and probably other things...
>
> Comments?
>
> -- Marshall
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
In reply to this post by Daniel Marjamäki via cfe-dev
Yes, this seems a good idea.  I think it is already clear enough that the experimental headers can't be relied upon for any long term, so having a specific cutoff date in there is good.  Maybe even mention it in the respective headers?

That said, on FreeBSD I didn't get any requests for adding the libc++experimental dynamic library, so I have simply omitted it.  Therefore, at least on FreeBSD there are no users of these features, so they won't be able to miss them either. :-)

-Dimitry

> On 10 Apr 2017, at 22:22, Marshall Clow via cfe-dev <[hidden email]> wrote:
>
> 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
>
> and probably other things...
>
> Comments?
>
> -- Marshall
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
In reply to this post by Daniel Marjamäki via cfe-dev
Marshall Clow via cfe-dev <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev

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, <[hidden email]> wrote:
Marshall Clow via cfe-dev <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
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
<[hidden email]> 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,
> <[hidden email]> wrote:
>>
>> Marshall Clow via cfe-dev <[hidden email]> 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
>> > [hidden email]
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
On Mon, Apr 10, 2017 at 3:39 PM, C Bergström <[hidden email]> 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
<[hidden email]> 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,
> <[hidden email]> wrote:
>>
>> Marshall Clow via cfe-dev <[hidden email]> 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
>> > [hidden email]
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
In reply to this post by Daniel Marjamäki via cfe-dev
On Mon, Apr 10, 2017 at 2:48 PM, Dimitry Andric <[hidden email]> wrote:
Yes, this seems a good idea.  I think it is already clear enough that the experimental headers can't be relied upon for any long term, so having a specific cutoff date in there is good.  Maybe even mention it in the respective headers?

That said, on FreeBSD I didn't get any requests for adding the libc++experimental dynamic library, so I have simply omitted it.  Therefore, at least on FreeBSD there are no users of these features, so they won't be able to miss them either. :-)

Well, no.
For example, std::experimental::string_view is header-only; there's no part of it that lives in the  libc++experimental lib.  It's not the only one.

-- Marshall


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] RFC: Plan for removing components from namespace std::experimental

Daniel Marjamäki via cfe-dev
In reply to this post by Daniel Marjamäki via cfe-dev
Will clang give warning or hint so that users know what's going on and what they can do?

Regards,
chenwj

2017-04-11 4:22 GMT+08:00 Marshall Clow via llvm-dev <[hidden email]>:
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

and probably other things...

Comments?

-- Marshall


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev




--

--
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Loading...