On 13/04/2022 19.32, Paolo Di Giglio via Std-Proposals wrote:
> Hi everybody,
>
> I finally managed to write down a draft for a proposal:
>
> https://pdigiglio.github.io/papers/tuple_protocol_for_c_style_arrays/draft0.html <https://pdigiglio.github.io/papers/tuple_protocol_for_c_style_arrays/draft0.html>
>
> I'd really like to have a feedback from you.

I think standard library types, in general, don't support volatile.
Supporting it here requires extra rationale.

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.

Otherwise looks straightforward.

Jens


> I left a "Questions" section, which I'll remove in later versions, with
> a remainder of things I couldn't figure out myself. I hope somebody here
> can help me out with those. Basically, the questions are:
>
> * volatile specializations for tuple_size and tuple_element have been
> deprecated since C++20 (and they're not mentioned in N4910).
> - Why were they deprecated?

Because volatile is generally frightening and implementation-defined.

> - Removing them from the standard wouldn't be a breaking change?
> - Should I propose specialization for volatile-qualified C-style
> arrays? (My guess is: no).

No.

> * Why is fixed-extent std::span not tuple like? Should I reach for Tim
> Song (author of P2116) to know the answer?

Yes, you should probably ask him.

Jens


> Thanks in advance.
>
> Best,
> Paolo
>
> Il giorno ven 11 mar 2022 alle ore 19:10 Zhihao Yuan via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> ha scritto:
>
> On Friday, March 11th, 2022 at 4:23 AM, Giuseppe D'Angelo via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> >
>
> > [...] I was just wondering if, historically, breaking
> > semantics w.r.t. plain arrays (and aligning on existing containers
> > instead) has always been a design choice or it "just happened" because
> > of multiple papers in flight at the same time.
> >
>
> > * array was added to TR1 in ~2003 (N1548, N1475)
> > * then got merged into the draft in ~2006 (N2003)
> > * ref qualifiers on *this was proposed in ~2005 (N1821)
> >
>
>
> I think you can still change it.
> Paper is welcome.
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> _______________________________________________
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>