C++ Logo

std-proposals

Advanced search

Re: [std-proposals] C-style array specialization for std::get

From: Paolo Di Giglio <p.digiglio91_at_[hidden]>
Date: Sun, 24 Apr 2022 18:38:58 +0200
Hi everybody,

I'd like to ping you again for a feedback on my last draft.

If there is none, I guess I should reach for the LEWG study-group
chairperson to submit my paper; right?

Thanks,
Paolo

Il giorno mar 19 apr 2022 alle ore 15:40 Paolo Di Giglio <
p.digiglio91_at_[hidden]> ha scritto:

> Hi everybody,
>
> You can find an updated version of my draft at the following URL:
>
>
> https://pdigiglio.github.io/papers/tuple_protocol_for_c_style_arrays/draft1.html
>
> With respect to draft0, I:
>
> * Dropped the volatile-qualified specializations (and discussed the
> behavior of std::tuple_element_t<0, int volatile[42]>).
>
> * Removed "Questions" section.
>
> I'm looking forward for your feedbacks.
>
> Thanks,
> Paolo
>
> Il giorno lun 18 apr 2022 alle ore 18:48 Zhihao Yuan <zy_at_[hidden]> ha
> scritto:
>
>> On Monday, April 18th, 2022 at 8:24 AM, Paolo Di Giglio <
>> p.digiglio91_at_[hidden]> wrote:
>>
>>
>> > 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
>>
>>
>> I'm not sure whether std::array supports
>> T volatile element type. It's very likely
>> array<T volatile, N> doesn't meet the
>> *Container*‚Äč requirements.
>>
>> Regardless, this can be discussed in
>> LEWG.
>>
>> --
>> Zhihao
>>
>>

Received on 2022-04-24 16:35:46