On Sat, Oct 29, 2022 at 10:33 PM blacktea hamburger <
greenteahamburger_at_[hidden]> wrote:

> 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.
>

apply requires a new replacement std::apply.


> 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.
>

I was wrong... The slices are of different kinds and not contiguous. So the
return types should be changed to the corresponding std::xxx_array<const
T>, and these specializations should only provide the const member
functions of std::valarray.


>
> 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.
>