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

### 754. Ambiguous return clause for `std::uninitialized_copy`

Section: 27.11.5 [uninitialized.copy] Status: NAD Editorial Submitter: Daniel Krügler Opened: 2007-10-15 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [uninitialized.copy].

View all issues with NAD Editorial status.

Discussion:

14882-2003, [lib.uninitialized.copy] is currently written as follows:

>     template <class InputIterator, class ForwardIterator>
>       ForwardIterator uninitialized_copy(InputIterator first, InputIterator last,
>                                          ForwardIterator result);

> > -1- Effects:

> > >     for (; first != last; ++result, ++first)
> > >       new (static_cast<void*>(&*result))
> > >         typename iterator_traits<ForwardIterator>::value_type(*first);

> > -2- Returns: `result`

similarily for N2369, and its corresponding section 27.11.5 [uninitialized.copy].

It's not clear to me what the return clause is supposed to mean, I see two possible interpretations:

1. The notion of `result` is supposed to mean the value given by the function parameter `result` [Note to the issue editor: Please use italics for `result`]. This seems somewhat implied by recognizing that both the function parameter and the name used in the clause do have the same italic font.
2. The notion of "result" is supposed to mean the value of `result` after the preceding effects clause. This is in fact what all implementations I checked do (and which is probably it's intend, because it matches the specification of `std::copy`).

The problem is: I see nothing in the standard which grants that this interpretation is correct, specifically [lib.structure.specifications] or 16.3.2.4 [structure.specifications] resp. do not clarify which "look-up" rules apply for names found in the elements of the detailed specifications - Do they relate to the corresponding synopsis or to the effects clause (or possibly other elements)? Fortunately most detailed descriptions are unambigious in this regard, e.g. this problem does not apply for `std::copy`.

Proposed resolution:

Change the wording of the return clause to say (27.11.5 [uninitialized.copy]):

> -2- Returns: The value of `result` after effects have taken place.

[ Bellevue: ]

> Resolution: NAD editorial -- project editor to decide if change is worthwhile. Concern is that there are many other places this might occur.