Re: [boost] TR2 is dead; multiple TR's coming instead

Subject: Re: [boost] TR2 is dead; multiple TR's coming instead
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-02-19 11:04:22

On Sat, Feb 18, 2012 at 3:40 PM, Brian Wood <woodbrian77_at_[hidden]> 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