Date: Sun, 12 Apr 2026 16:10:46 +0200
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.
> 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.
Received on 2026-04-12 14:10:59