Thank you so so much for clarification.

On Sun, 12 Apr 2026, 7:10 pm Simon Schröder, <dr.simon.schroeder_at_[hidden]>
wrote:

> I guess I was a little too quick to reply. When I am writing “it needs a
> discussion” it does not mean we need to discuss this on the list. Instead I
> mean there needs to be a discussion in the written proposal itself. The
> proposal needs to state that there are different possible solutions to the
> problem or that we could restrict the allowed types or not. And take one
> side and provide a reason why it is the proposed solution. (Basically it is
> arguing with yourself in the proposal so that the committee can follow why
> you made certain decisions.)
>
> > On Apr 12, 2026, at 4:06 PM, Simon Schröder <
> dr.simon.schroeder_at_[hidden]> wrote:
> >
> > 
> >
> >>> On Apr 12, 2026, at 11:59 AM, Muneem <itfllow123_at_[hidden]> wrote:
> >>>
> >>> Extending std::tuple with operator[] also needs one discussion: Do we
> only allow this if all the types inside the tuple are distinct? I don’t see
> it necessary for proposing this extension. However, I’d want for the
> implementation of operator[] to make the types of the std::variant returned
> to be distinct even if the types of std::tuple are not.
> >> ***ANSWER***: It does require a discussion, but what do you mean by
> "distinct"? like in what way? is the variant gonna handle them differently?
> > I’m a little tired, so you get just a short reply: Currently, you can
> write std::tuple<int,int,int>. These types are all the same. With
> std::tuple<int,float,string> they are all different, i.e. distinct from
> each other. So, for std::tuple<int,int,int> the easy implementation is for
> operator[] to return std::variant<int&,int&,int&>. This is allowed, but we
> can’t use std::get<int&>() anymore, but only std::get<1>() (or any other
> valid index). If we follow this route, it is also not possible to
> automatically construct a std::optional<int&> from a std:
> variant<int&,int&,int&>. The solution (and you already posted that it is
> possible) is to reduce it to just std::variant<int&> in this case. I don’t
> see a general problem with allowing std::tuple<int,float,int>, but it needs
> to be discussed if operator[] is implemented in this case.
>