This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

### 527. `tr1::bind` has lost its Throws clause

Section: 20.14.15.4 [func.bind.bind], 99 [tr.func.bind.bind] Status: CD1 Submitter: Peter Dimov Opened: 2005-10-01 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [func.bind.bind].

View all issues with CD1 status.

Discussion:

The original bind proposal gives the guarantee that `tr1::bind(f, t1, ..., tN)` does not throw when the copy constructors of `f, t1, ..., tN` don't.

This guarantee is not present in the final version of TR1.

I'm pretty certain that we never removed it on purpose. Editorial omission? :-)

[ Berlin: not quite editorial, needs proposed wording. ]

[ Batavia: Doug to translate wording to variadic templates. ]

[ Toronto: We agree but aren't quite happy with the wording. The "t"'s no longer refer to anything. Alan to provide improved wording. ]

[ Pre-Bellevue: Alisdair provided wording. ]

TR1 proposed resolution:

> In 99 [tr.func.bind.bind], add a new paragraph after p2:

> > Throws: Nothing unless one of the copy constructors of `f, t1, t2, ..., tN` throws an exception.

> Add a new paragraph after p4:

> > Throws: nothing unless one of the copy constructors of `f, t1, t2, ..., tN` throws an exception.

Proposed resolution:

In 20.14.15.4 [func.bind.bind], add a new paragraph after p2:

> Throws: Nothing unless the copy constructor of `F` or of one of the types in the `BoundArgs...` pack expansion throws an exception.

In 20.14.15.4 [func.bind.bind], add a new paragraph after p4:

> Throws: Nothing unless the copy constructor of `F` or of one of the types in the `BoundArgs...` pack expansion throws an exception.