> I slightly prefer the constraining specification, so that you don't
> need to thinking about the fate of volatile tuple_element.

I believe you need to think about volatile in either case.

The subtlety with C-style array types is that there's no difference
between applying a cv-qualifier to the array or to the element type:
i.e. a constant array of N integers is the same as an array of N
constant integers. This is not the case with std::array.

My understanding is that the standard will drop the tuple-protocol
support for volatile-qualified std::array; not for std::array of
volatile-qualified elements. I.e.

//using namespace std;
tuple_element_t<0, array<int, 42> volatile> // Won't compile
tuple_element_t<0, array<int volatile, 42>> // Ok: int volatile

So, I believe the following should work:

//using namespace std;
tuple_element_t<0, int volatile [42]> // int volatile
tuple_element_t<0, int volatile const[42]> // int volatile const

To accomplish this with my paper I need to:

 * drop the proposed volatile specializations;
 * change the requires clause to is_same_v<T, remove_const_t<T>>
 in section 4.2.

Now, I don't have any strong argument to prefer the const specialization
over the constraining specialization nor vice versa. I find the former
slightly clearer but that's a matter of opinion.


Il giorno gio 14 apr 2022 alle ore 18:38 Zhihao Yuan <zy_at_[hidden]> ha
scritto:

> On Thursday, April 14th, 2022 at 8:54 AM, Paolo Di Giglio via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Hi Jens,
> > I think there is a already a mapping from "const T" to "T" for
> > tuple_size and tuple_element, so you don't need those specializations.
> The reason why you need the "T const[N]" specializations is because such
> mapping exists. I explain that in section 4.1.1. Please have a look and
> let me know what you think.
>
> I introduced "T volatile[N]" and "T volatile const[N]" specializations
> because similar mappings from "T volatile" and "T volatile const" to "T"
> existed up to C++20. I'll remove these specializations from my paper
> since the mappings will be removed in C++23.
>
>
> I see. I slightly prefer the constraining
> specification, so that you don't need
> to thinking about the fate of volatile
> tuple_element.
>
> --
> Zhihao
>