The standard fails to specify the behavior of valarray::operator[](slice)
and other valarray subset operations when they are passed an "invalid"
slice object, i.e., either a slice that doesn't make sense at all (e.g.,
slice (0, 1, 0) or one that doesn't specify a valid subset of the valarray
object (e.g., slice (2, 1, 1) for a valarray of size 1).

[Kona: the LWG believes that invalid slices should invoke
undefined behavior. Valarrays are supposed to be designed for high
performance, so we don't want to require specific checking. We
need wording to express this decision.]

[
Bellevue:
]

Please note that the standard also fails to specify the behavior of
slice_array and gslice_array in the valid case. Bill Plauger will
endeavor to provide revised wording for slice_array and gslice_array.

[
post-Bellevue: Bill provided wording.
]

[
2009-07 Frankfurt
]

Move to Ready.

[
2009-11-04 Pete opens:
]

The resolution to LWG issue 430 has not been applied — there have been
changes to the underlying text, and the resolution needs to be reworked.

The member operator is overloaded to provide several ways to select
sequences of elements from among those controlled by *this.
Each of these operations returns a subset of the array. The
const-qualified versions return this subset as a new valarray. The
non-const versions return a class template object which has reference
semantics to the original array, working in conjunction with various
overloads of operator= (and other assigning operators) to allow
selective replacement (slicing) of the controlled sequence. In each case
the selected element(s) must exist.

valarray<T> operator[](slice slicearr) const;

This function returns an object of class valarray<T>
containing those elements of the controlled sequence designated by
slicearr. [Example: