Re: [boost] TR2 is dead; multiple TR's coming instead
Beman Dawes :
The C++ committee met last week. There was lot's of discussion and plans to markedly increase the size of the standard library. Boost has an important part to play; Bjarne Stroustrup hoped for "doubling the output of Boost."
Sounds like Pharoah, but I'm sure he meant to be encouraging.
Here are some of the process changes:
* Library proposals will be taken on as "work Items". A decision as to whether a work item ends up in a technical report, in the standard itself, or even becomes a stand-alone international standard, will be deferred until technical work is complete (I.E. full standardese complete, polished, and ready to ship).
* Domain specific "Study Groups" will replace the LWG's current sub-groups. Study groups have official ISO standing, so can get more work done between meetings than the old sub-groups, which were unofficial.
* Technical reports will likely be smaller than in the past, and may be domain specific.
How will they be named? I'm fine with multiple TRs, but calling the next one TR2 seems reasonable to me.
These changes are intended to allow work on different libraries to proceed in parallel. Medium to large libraries managed by study groups will most likely end up as a TRs and will ship when ready rather than being held waiting for a larger TR to become ready.
The study groups set up so far:
* SG1: Concurrency and Parallelism (chair: Hans Boehm). This is the old Concurrency sub-group.
* SG2: Modules (chair: Doug Gregor). A new sub-group of the committee's evolution working group (EWG).
I'm hoping there will be support for partial classes here. I don't think Vandevoorde's proposal takes this into account. Is there another modules proposal?
* SG3: File System (chair: Beman Dawes). A LWG sub-group to handle the Boost.Filesystem work item approved at the meeting.
* SG4: Networking (chair: Kyle Kloepper). A LWG sub-group to handle the Boost.Asio work item approved at the meeting.
It looks like cryptography is slipping through the cracks. If there are signs of life in the crypto lib you're using please let me know.
There should be a "Call for Library Proposals" in the committee's post-meeting mailing in roughly 10 days.
While C++ needs more libraries, I'd like to see it get rid of/improve some existing libraries. Herb mentioned valarray being little used. I think that's right. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net "Prepare your work without, and make it fit for yourself in the field; and afterward build your house." Proverbs 24:27
On Sat, Feb 18, 2012 at 3:40 PM, Brian Wood <woodbrian77@gmail.com> wrote:
Beman Dawes : ...
* Technical reports will likely be smaller than in the past, and may be domain specific.
How will they be named? I'm fine with multiple TRs, but calling the next one TR2 seems reasonable to me.
Probably with the domain name. Filesystem TR, Networking TR, etc.
* SG2: Modules (chair: Doug Gregor). A new sub-group of the committee's evolution working group (EWG).
I'm hoping there will be support for partial classes here. I don't think Vandevoorde's proposal takes this into account.
I was tied up in LWG all week and didn't sit in on the module discussions. Evolution is also breaking work into parallel tracks. Minor language tweaks that don't require rework of the current library workload or is particularly complex on a track for the 2017 time frame, while stuff that has a big impact on the library or is otherwise complex or time consuming on a track for 2022. It isn't clear yet which track modules belong to. That may end up depending on how many features get added.
Is there another modules proposal?
I'm not aware of any, but that's outside my orbit. Also, this study group is just starting up, so it is still early days with nothing yet cast in concrete.
* SG3: File System (chair: Beman Dawes). A LWG sub-group to handle the Boost.Filesystem work item approved at the meeting.
* SG4: Networking (chair: Kyle Kloepper). A LWG sub-group to handle the Boost.Asio work item approved at the meeting.
It looks like cryptography is slipping through the cracks.
Whoa! There hasn't even been a call for proposals yet! The work at this meeting was just on stuff that was already in the pipeline from years past.
If there are signs of life in the crypto lib you're using please let me know.
I'm the wrong person to ask about crypto.
While C++ needs more libraries, I'd like to see it get rid of/improve some existing libraries. Herb mentioned valarray being little used. I think that's right.
Work continues on processing issues; that's ongoing and never ending. There are also some proposals on the table (range, basic_string_ref, and my string interop stuff, to name three) that aim at improving existing library use. Thanks, --Beman
From: bdawes@acm.org
Evolution is also breaking work into parallel tracks. Minor language tweaks that don't require rework of the current library workload or is particularly complex on a track for the 2017 time frame, while stuff that has a big impact on the library or is otherwise complex or time consuming on a track for 2022.
It isn't clear yet which track modules belong to. That may end up depending on how many features get added.
This may be slightly OT, but do you know which track concepts belong to? I have really been hoping that we don't have to wait so long for concepts... Thanks, Nate
On Sun, Feb 19, 2012 at 2:08 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
From: bdawes@acm.org
Evolution is also breaking work into parallel tracks. Minor language tweaks that don't require rework of the current library workload or is particularly complex on a track for the 2017 time frame, while stuff that has a big impact on the library or is otherwise complex or time consuming on a track for 2022.
It isn't clear yet which track modules belong to. That may end up depending on how many features get added.
This may be slightly OT, but do you know which track concepts belong to?
Tentatively 2022, although experimental compilers are likely to be available much sooner. There is concern that 2017 is too soon for language changes that have a major impact on the library and on users, and that C++11 changes need to be fully implemented and absorbed by the community first.
I have really been hoping that we don't have to wait so long for concepts...
Concepts work continues. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf, A Concept Design for the STL. --Beman
On 2/20/2012 6:03 AM, Beman Dawes wrote:
On Sun, Feb 19, 2012 at 2:08 PM, Nathan Ridge<zeratul976@hotmail.com> wrote:
From: bdawes@acm.org
Evolution is also breaking work into parallel tracks. Minor language tweaks that don't require rework of the current library workload or is particularly complex on a track for the 2017 time frame, while stuff that has a big impact on the library or is otherwise complex or time consuming on a track for 2022.
It isn't clear yet which track modules belong to. That may end up depending on how many features get added.
This may be slightly OT, but do you know which track concepts belong to?
Tentatively 2022, although experimental compilers are likely to be available much sooner.
There is concern that 2017 is too soon for language changes that have a major impact on the library and on users, and that C++11 changes need to be fully implemented and absorbed by the community first.
It is disappointing to hear that it is anticipated that it will take another decade before 'concepts' become an official part of C++, considering how close it came to acceptance for C++11. I am seriously hoping that interested parties will see that adding 'concepts' to C++ much sooner is very important to the language, especially for those doing template programming.
----- Original Message -----
From: Edward Diener <eldiener@tropicsoft.com> To: boost@lists.boost.org Cc: Sent: Monday, February 20, 2012 11:37 PM Subject: Re: [boost] TR2 is dead; multiple TR's coming instead
On Sun, Feb 19, 2012 at 2:08 PM, Nathan Ridge<zeratul976@hotmail.com> wrote:
From: bdawes@acm.org
Evolution is also breaking work into parallel tracks. Minor language tweaks that don't require rework of the current
On 2/20/2012 6:03 AM, Beman Dawes wrote: library
workload or is particularly complex on a track for the 2017 time frame, while stuff that has a big impact on the library or is otherwise complex or time consuming on a track for 2022.
It isn't clear yet which track modules belong to. That may end up depending on how many features get added.
This may be slightly OT, but do you know which track concepts belong to?
Tentatively 2022, although experimental compilers are likely to be available much sooner.
There is concern that 2017 is too soon for language changes that have a major impact on the library and on users, and that C++11 changes need to be fully implemented and absorbed by the community first.
It is disappointing to hear that it is anticipated that it will take another decade before 'concepts' become an official part of C++, considering how close it came to acceptance for C++11. I am seriously hoping that interested parties will see that adding 'concepts' to C++ much sooner is very important to the language, especially for those doing template programming.
However, with the new C++11 features, such as sfinae for expressions, template aliases, and forwarding, I think a library could be created to emulate much of the features. The feature I think is the most pressing is the polymorphic lambdas, or at least improving the use of lambda in polymorphic functions. Thats just my two cents. -paul
The feature I think is the most pressing is the polymorphic lambdas, or at least improving the use of lambda in polymorphic functions.
Modules obviously come first ;)
Yes, modules is more important, but it is a whole new feature, and polymorphic lambdas is a fix to a current feature. I just assume it would be faster to get polymorphic lambdas through.
participants (6)
-
Beman Dawes -
Brian Wood -
Edward Diener -
Julien Nitard -
Nathan Ridge -
paul Fultz