std::valarray is generally considered a rarely used and unsupported
library. IMO one of the reasons is that it is missing something and has
some issues. I propose extensions and fixes in the following areas:

1. Make std::valarray more like a container:

This is not to make std::valarray really a container, but to add some
member functions/types that are also useful to it.

Member functions:

   - begin/cbegin
   - end/cend
   - rbegin/crbegin
   - rend/crend
   - empty
   - data
   - front
   - back

Making begin/end member functions improves consistency and provides better
syntax.

Member types:

   - value_type
   - size_type
   - difference_type
   - reference/const_reference
   - iterator/const_iterator
   - reverse_iterator/const_reverse_iterator

2. Deprecation:

Deprecate sum, min, max, shift, cshift
and apply, use std::accumulate, std::max_element, std::min_element,
std::shift_left, std::rotate and std::for_each instead.

3. Helper class improvements:

The helper classes for std::valarray should be able to access the
referenced element, so they should provide all member functions of
std::valarray except resize and data.

The const-qualified versions of operator[] return a subset as a new
valarray object. There is a performance penalty for such a copy, so I
propose to introduce std::valarray_view, which refers to a constant
sequence of contiguous elements, like std::basic_string_view. It should be
like other helper classes, but only provide all the const member functions
of std::valarray. It won't break compatibility because implementations can
substitute the return type per [valarray.syn]/3-5.

4. std::cbrt(std::valarray)

This may depend on whether std::cbrt(std::complex) is provided, but even if
it is not provided, it makes sense for std::valarray with elements of real
numbers.

I wish there were more opinions.