Proposed resolution:

In order to allow these algorithms to operate on volatile storage I propose to change the expression so as to make it well-formed even for pointers to volatile types. Specifically, I propose the following changes to clauses 20 and 24. Change 20.6.4.1, p1 to read:

Effects:

typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
typedef typename iterator_traits<ForwardIterator>::value_type value_type;

for (; first != last; ++result, ++first)
    new (static_cast<void*>(const_cast<pointer>(&*result))
        value_type (*first);

            

change 20.6.4.2, p1 to read

Effects:

typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
typedef typename iterator_traits<ForwardIterator>::value_type value_type;

for (; first != last; ++result, ++first)
    new (static_cast<void*>(const_cast<pointer>(&*first))
        value_type (*x);

            

and change 20.6.4.3, p1 to read

Effects:

typedef typename iterator_traits<ForwardIterator>::pointer    pointer;
typedef typename iterator_traits<ForwardIterator>::value_type value_type;

for (; n--; ++first)
    new (static_cast<void*>(const_cast<pointer>(&*first))
        value_type (*x);

            

In addition, since there is no partial specialization for iterator_traits<volatile T*> I propose to add one to parallel such specialization for <const T*>. Specifically, I propose to add the following text to the end of 24.3.1, p3:

and for pointers to volatile as

namespace std {
template<class T> struct iterator_traits<volatile T*> {
typedef ptrdiff_t difference_type;
typedef T value_type;
typedef volatile T* pointer;
typedef volatile T& reference;
typedef random_access_iterator_tag iterator_category;
};
}

            

Note that the change to iterator_traits isn't necessary in order to implement the specialized algorithms in a way that allows them to operate on volatile strorage. It is only necesassary in order to specify their effects in terms of iterator_traits as is done here. Implementations can (and some do) achieve the same effect by means of function template overloading.

[ 2009-07 Frankfurt ]

We don't deal with volatile in the library.

Jim: should we state that explicitly somewhere?

Beman: you might argue that clause 17 should say something about volatile. However, if you want to raise we argument, we should open it as a separate issue and consult with experts on concurrency.

Hinnant: actually, some library components do handle volatile, so we'd need to be very careful about what we say in clause 17.

No objection to NAD.

Move to NAD.

[ 2009-06-17 Pablo adds: ]

Propose that Issue 582 be closed NAD.

Issue 582 asks that uninitialized_copy, uninitialized_fill, and uninitialized_fill_n should be well-formed if the result type is volatile. My feeling is that the standard does not, and should not, guarantee any useful behavior when constructors are invoked on volatile storage, so making it syntactically legal to call uninitialized_copy on volatile storage is not useful. A possible editorial change would be to put my previous sentence into a non-normative note.

Note that the three sections starting with [uninitialized.copy] do not yet have concepts. Here's a first crack at the first one:

template <InputIterator InIter, OutputIterator OutIter>
requires ExplicitConvertible<HasDereference<OutIter::reference>::result,
                             OutIter::value_type&>
      && Convertible<OutIter::value_type*, void*>
      && ExplicitConvertible<OutIter::value_type, InIter::reference>
  OutIter uninitialized_copy(InIter first, InIter last, OutIter result);

Effects:

while (first != last) {
  typedef OutIter::value_type value_type;
  value_type& outRef = static_cast<value_type&>(*result++);
  ::new (static_cast<void*>(addressof(outRef))) value_type(*first++);
}

Notes:

1. This definition is actually LESS constrained than in C++03 because there is no requirement that the result be a forward iterator.
2. If OutIter returns a proxy type with an overloaded operator&, this definition probably won't compile. Lifting this limitation while allowing value_type to have an overloaded operator& would be hard, but is probably possible with careful overloading. I'm not sure it's worth it.
3. This definition retains the prohibition on the use of volatile types for the result.

[ Batavia: Lack of support for proposed resolution but agree there is a defect. Howard to look at wording. Concern that move semantics properly expressed if iterator returns rvalue. ]

Related to 1029

The specialized algorithms [lib.specialized.algorithms] are specified as having the general effect of invoking the following expression:

new (static_cast<void*>(&*i))
    typename iterator_traits<ForwardIterator>::value_type (x)

            

This expression is ill-formed when the type of the subexpression &*i is some volatile-qualified T.