On 4/10/26 20:01, Simon Schröder via Std-Proposals wrote:
>std::optional<int&> x = list[0];
Just to make sure that we are on the same page:
we both agree that "std::optional<int&> x = list[index];"
1. std::optional<int&> 's constructor should throw an exception if the
variant returned by list[index] is not an int.
2. For std::variant<T&...> to work, we need support from the implementation
just like the support I needed for type_set<T...>, this support would be
import such that we can avoid the T& to be changed, and since unions cant
have references, the implementation would need to come up with some
internal implementation.

Note: the branching that I talked about for "std::variant<T&...>
specialization to to some std::optional<T&> at runtime" in my email to
Mr.David Brown is the checking in point one.

On 4/10/26 20:01, Bjorne Reese via Std-Proposals wrote:
>> 2. Add operator[] to std::tuple which returns const std::variant<Ts&…>

>Better yet, a free function that works with any tuple-like object.

1. I can agree that it will be convenient, but I would also love to
emphasize that there should be a specific member function for the specific
tuple<T&...> meant for runtime that has its own different implementation.

On Sat, Apr 11, 2026 at 10:21 AM Muneem <itfllow123_at_[hidden]> wrote:

> My response my Mr.Thiago Let's forget the bench marks for a second, and
> focus on the larger image of the limitations that I faced In implementing a
> dynamic type system. Micro dispatches may not matter on a small scale but
> it's like if if statements get slower then the effect is small in small
> projects and large in large ones. Similiarly if you were to access variants
> again and again and again, then you have the effect of the 13500% slower
> speed increased. Again, dynamic typing is not a esoteric branch of
> programming, infact as people move towards building large infrusture to
> connect AI tools to automated scripts and to help them operate those tools,
> we need real time systems, and real time systems often require flexibility
> as they become complex. In the case of my virtual machine, it was meant to
> be a simple way to build compilers but ended up having a whole large file
> for dynamic typing. I would argue that the reason Python is used to deal
> with large systems operated by AI or some other system is precisely because
> it supports dynamic typing(cuz it's interpreted). In the case of python,
> it's slow and the way it does dynamic typing is rather not strict
> enough(duck typing behaviours) that though could be mitigated with newer
> type constrained features are still causing issues in existing python code
> bases. C++ on the other hands can support dynamic typing in way that allows
> for strict closed set dynamic typing only. If that happens then people
> would have no reason to use python over C++ in the majority of cases,
> except the ones where you just want to automate a small task.
>
> On Fri, 10 Apr 2026, 8:02 pm Thiago Macieira via Std-Proposals, <
> std-proposals_at_[hidden]> wrote:
>
>> On Friday, 10 April 2026 04:34:24 Pacific Daylight Time Muneem via Std-
>> Proposals wrote:
>> > Why do we need to go in circles? Like std::variant is a union hence not
>> > STRICTLY DYNAMICALLY TYPED.
>>
>> No, it isn't. That depends on the code you write. You can very well
>> operate
>> only on the type it currently has, without changing.
>>
>> For the purpose you've espoused -- using one of many possible list
>> implementations -- std::variant *works* *just* *fine*.
>>
>> From the analyses of the assembly generated by the compiler in the
>> benchmarks
>> you posted about a week ago, the difference is only where the "current
>> type" is
>> kept. With std::variant, since it is kept inside of the variant, the code
>> emitted by the compiler ends up checking it every time. Quite likely, if
>> you
>> had two visitors back-to-back, the compiler would fail to realise it's
>> the
>> same current type and do two dispatches. That's a QoI problem and can be
>> fixed
>> in the compiler.
>>
>> With your external type selection, the compiler has an easier time
>> proving the
>> choice did not change and thus optimise the code to make a single
>> dispatch to
>> multiple visitors.
>>
>> That doesn't mean we need a new type. In real-world scenarios, the cost
>> of
>> extra dispatches is likely negligible -- as it was in the
>> micro-benchmarks.
>> There may be some edge cases where it is meaningful, but that does not
>> imply
>> the solution needs to be in the Standard Library. There are many
>> specialised
>> algorithms and containers that aren't due to their limited usefulness to
>> the
>> general public. Moreover, there is a cost in *adding* them: maintenance
>> by the
>> implementations, teachability, readability, etc.
>>
>> And more importantly, NONE of this implies we need a language change.
>> That
>> should be an orthogonal discussion.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>