Re: [boost] [function] function wrapping with noexceptionsafetyguarantee

Subject: Re: [boost] [function] function wrapping with noexceptionsafetyguarantee
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-10-20 17:02:50

On Tue, Oct 19, 2010 at 6:20 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:
> ----- Original Message -----
> From: "Emil Dotchevski" <emil_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Wednesday, October 20, 2010 12:06 AM
> Subject: Re: [boost] [function] function wrapping with noexceptionsafetyguarantee
>
>
>>
>> On Tue, Oct 19, 2010 at 3:03 PM, vicente.botet <vicente.botet_at_[hidden]> wrote:
>>> ----- Original Message -----
>>> From: "Joel Falcou" <joel.falcou_at_[hidden]>
>>> To: <boost_at_[hidden]>
>>> Sent: Tuesday, October 19, 2010 10:06 AM
>>> Subject: Re: [boost] [function] function wrapping with noexception safetyguarantee
>>>
>>>
>>>> On 19/10/10 09:56, Emil Dotchevski wrote:
>>>>> Even if there were sufficient demand to change boost::function, that's
>>>>> not how Boost works. Each Boost library has a maintainer and once the
>>>>> library is accepted, (s)he needs to be sold on the change.
>>>>>
>>>>> There's also the issue that it seems a good idea to keep
>>>>> boost::function unchanged so it doesn't deviate from std::function.
>>>>
>>>> can't we resort to an artifice like function2, much like signal and
>>>> signal2 coexists ?
>>>
>>> +1, but we need someone to do the work :(
>>
>> What's the benefit of function2 vs. adding a nothrow_t constructor to function?
>
> I have not followed all the change request to boost::function but it seems to me that not all are compatible with the current interface. So my opinion is that the people that are interested in the change make a conrete proposal in the form of a new library or a library extension and we will see if the proposal is accepted by the Boost community.
>
> Change requests that break the interface should not be acceptable in principle.

FYI, there is already a boost::function2. It's a portable, binary
function wrapper that works on compilers without partial
specialization.

http://www.boost.org/doc/libs/1_44_0/doc/html/boost/functionN.html#id1273294

However, I do agree that the best solution is to leave boost::function
as is and provide an alternative function wrapper with alternative
semantics. unsafe_function is a simple way to do that.

Daniel Walker