Also, vector<vector<type_tag>> isn't a mistake, like the allocator is
implicit and the outer ">" is placed, but again, it's my fault to not use:
Using vector_of_type_tag= vector<type_tag>
Then
Vector<vector_of_type_tag>
Deque<vector_of_type_tag>
So I am sorry for that.

On Tue, 31 Mar 2026, 12:25 am Muneem, <itfllow123_at_[hidden]> wrote:

> I am sorry for the bad presentation, I will reformat it and then repost.
>
> On Tue, 31 Mar 2026, 12:25 am Muneem, <itfllow123_at_[hidden]> wrote:
>
>> First, I promise that it's not AI slop. Second, I am 17 so my Grammer is
>> naturally just bad. Third, it's my first time, so all I did was to go to
>> the docs, they told me to write a messy paper, the expert would critique
>> it, and I will fix the format and send it to you. As far as the content
>> goes, it was meant to be pseudo code, like I didn't want to make the code
>> too long, like for me, it was about getting to the point, since the iso
>> standard drafts are also messy, so I thought pseudo code is your language.
>>
>> On Tue, 31 Mar 2026, 12:03 am , <std-proposals-request_at_[hidden]>
>> wrote:
>>
>>> Send Std-Proposals mailing list submissions to
>>> std-proposals_at_[hidden]
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>> or, via email, send a message with subject or body 'help' to
>>> std-proposals-request_at_[hidden]
>>>
>>> You can reach the person managing the list at
>>> std-proposals-owner_at_[hidden]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of Std-Proposals digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>> 1. `random_access_iterator_accessor` for `std::mdspan`? (Hewill Kang)
>>> 2. Re: Proposal to extended dynamic polymorphism (to fix issues
>>> that std::variant fails at addressing) (Thiago Macieira)
>>> 3. Re: Proposal to extended dynamic polymorphism (to fix issues
>>> that std::variant fails at addressing) (Jason McKesson)
>>> 4. Re: Benchmarking contract evaluation semantics mode "assume"
>>> in Eigen. (Adrian Johnston)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Mon, 30 Mar 2026 20:33:20 +0800
>>> From: Hewill Kang <hewillk_at_[hidden]>
>>> To: std-proposals <std-proposals_at_[hidden]>
>>> Subject: [std-proposals] `random_access_iterator_accessor` for
>>> `std::mdspan`?
>>> Message-ID:
>>> <
>>> CACoQM8jKKhsKuX1Mbvd2pzpjoOj2Xzy70_Y+Z7S8WDtvyZHqaA_at_[hidden]>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi all,
>>>
>>> Currently, although `mdspan` is designed as a general-purpose multiview,
>>> it
>>> mostly accepts a pointer and accesses different elements through a
>>> pointer
>>> algorithm.
>>> However, I am not satisfied with these *pointer*-based mandates because I
>>> do not think they are much different from a general
>>> `contiguous_iterator`,
>>> which can be a common iterator such as `vector::iterator`.
>>> If we look at the `default_accessor`, we can see the clue:
>>>
>>> ```cpp
>>> template<class ElementType>
>>> struct default_accessor {
>>> using offset_policy = default_accessor;
>>> using element_type = ElementType;
>>> using reference = ElementType&;
>>> using data_handle_type = ElementType*;
>>>
>>> constexpr default_accessor() noexcept = default;
>>> constexpr reference access(data_handle_type p, size_t i) const
>>> noexcept
>>> { return p[i]; }
>>> constexpr data_handle_type offset(data_handle_type p, size_t i) const
>>> noexcept
>>> { return p + i; }
>>> };
>>> ```
>>> Then, upon closer inspection, we discovered that this is *exactly* the
>>> operation supported by C++20 `random_access_iterator`, i.e.,
>>> `operator[]` and `operator+`.
>>> Given this, I think we can introduce a new accessor class that wraps the
>>> `random_access_iterator`, for example:
>>>
>>> ```cpp
>>> template<random_access_iterator I>
>>> struct *iter_accessor* {
>>> using offset_policy = iter_accessor;
>>> using reference = iter_reference_t<I>;
>>> using element_type = remove_reference_t<reference>;
>>> using data_handle_type = I;
>>>
>>> iter_accessor() noexcept = default;
>>> constexpr reference
>>> access(data_handle_type p, std::iter_difference_t<I> i) const
>>> { return p[i]; }
>>> constexpr data_handle_type
>>> offset(data_handle_type p, std::iter_difference_t<I> i) const
>>> { return p + i; }
>>> };
>>> ```
>>>
>>> This fully inherits the natural characteristics of a
>>> `random_access_iterator`, which allows us to very easily make `mdspan`s
>>> with a wide variety of different `random_access_range`s, such as:
>>>
>>> ```
>>> using Layout = std::layout_right::mapping<std::extents<int, 3, 3>>;
>>>
>>> auto r = std::views::iota(0, 9);
>>> auto ms1 = std::mdspan(r.begin(), Layout{}, *iter_accessor*
>>> <decltype(r.begin())>{});
>>> /* 0 1 2
>>> 3 4 5
>>> 6 7 8 */
>>>
>>> auto v = std::vector<bool>{true, false, true, false, true, false, true,
>>> false, true};
>>> auto ms2 = std::mdspan(v.begin(), Layout{}, *iter_accessor*
>>> <decltype(v.begin())>{});
>>> /* true false true
>>> false true false
>>> true false true */
>>>
>>> std::vector<int> v1{1, 2, 3}, v2{4, 5}, v3{};
>>> std::array a{6, 7, 8};
>>> auto s = std::views::single(9);
>>> auto r3 = std::views::concat(v1, v2, v3, a, s);
>>> auto ms3 = std::mdspan(r3.begin(), Layout{}, *iter_accessor*
>>> <decltype(r3.begin())>{});
>>> /* 1 2 3
>>> 4 5 6
>>> 7 8 9 */
>>> ```
>>> Demo: https://godbolt.org/z/xb5vrejba
>>>
>>> I think this is a very useful utility.
>>> Based on C++26, we have a large majority of range adaptors in `<ranges>`
>>> that can support `random_access_range`.
>>> Introducing this `accessor` makes them better integrated with `mdspan`,
>>> which also opens the door for third-party custom range types.
>>>
>>> What do you think? Appreciate any feedback.
>>>
>>> Hewill
>>> -------------- next part --------------
>>> HTML attachment scrubbed and removed
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Mon, 30 Mar 2026 10:32:39 -0400
>>> From: Thiago Macieira <thiago_at_[hidden]>
>>> To: std-proposals_at_[hidden]
>>> Subject: Re: [std-proposals] Proposal to extended dynamic polymorphism
>>> (to fix issues that std::variant fails at addressing)
>>> Message-ID: <5064962.UPlyArG6xL_at_[hidden]>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> On Monday, 30 March 2026 02:06:42 Eastern Daylight Time Muneem via Std-
>>> Proposals wrote:
>>> > Recently, I faced some issues in writing code that relied heavily on
>>> > repetitive branching, which forced me to use AI. This proposal proposes
>>> > techniques to counter this, in cases where the overhead of single
>>> dispatch
>>> > is highly undesirable.
>>>
>>> Hello Muneem
>>>
>>> The C++ Standard is published by the International Standards
>>> Organisation
>>> (ISO) and ISO currently has strict rules on the use of AI, especially
>>> but not
>>> limited to copyright. Please make sure *you* have written the proposal,
>>> not
>>> the AI (you can use it for some research, spell-checking, things like
>>> that).
>>> Otherwise, we can't even discuss it.
>>>
>>> When posting a proposal for discussion, it's also a good idea to include
>>> a
>>> summary/abstract of what you're trying to achieve in the body of the
>>> email,
>>> not just somewhere on the web. If I were reading this on the plane with
>>> off-
>>> line emails, I couldn't open your proposal.
>>>
>>> --
>>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>>> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: signature.asc
>>> Type: application/pgp-signature
>>> Size: 870 bytes
>>> Desc: This is a digitally signed message part.
>>> URL: <
>>> https://lists.isocpp.org/std-proposals/attachments/20260330/534768ac/attachment.sig
>>> >
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Mon, 30 Mar 2026 11:13:32 -0400
>>> From: Jason McKesson <jmckesson_at_[hidden]>
>>> To: std-proposals_at_[hidden]
>>> Subject: Re: [std-proposals] Proposal to extended dynamic polymorphism
>>> (to fix issues that std::variant fails at addressing)
>>> Message-ID:
>>> <
>>> CANLtd3V2hH4YwthAp4hrUZM9zJcOg+JeC3gyjiSynyRR8vGVfw_at_[hidden]>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> On Mon, Mar 30, 2026 at 2:07?AM Muneem via Std-Proposals
>>> <std-proposals_at_[hidden]> wrote:
>>> >
>>> > Recently, I faced some issues in writing code that relied heavily on
>>> repetitive branching, which forced me to use AI. This proposal proposes
>>> techniques to counter this, in cases where the overhead of single dispatch
>>> is highly undesirable.
>>>
>>> Let's start off with the form of your proposal.
>>>
>>> Using a text file is fine, in so far as being able to read it goes.
>>> The problem is the formatting; it's bad. None of the code is properly
>>> indented, which makes reading it a huge pain. Paragraphs are neither
>>> indented nor double-spaced. Grammar is all over the place; sometimes
>>> you capitalize `I` correctly; sometimes you don't. Your code contains
>>> obvious errors, like a lack of `break` statements in switch/case.
>>>
>>> Overall, purely from a presentation perspective, it is very difficult
>>> to read and get any information out of it.
>>>
>>> In terms of the content, it's not much better. You mention this type:
>>>
>>> vector<vector<type_tag>>, deque<vector<type_tag>>
>>>
>>> That's not how `std::vector` works. The second template argument needs
>>> to be an allocator, which `std::deque` is not. So is this your own
>>> `vector` type or is this just nonsense code.
>>>
>>> The code you linked to does not seem to be valid C++. It features both
>>> `if constexpr` and `constexpr if`. Only one of those is legal C++.
>>>
>>> Overall, this seems to be slop. Whether AI generated or human
>>> generated is irrelevant. Maybe there's a coherent idea in there
>>> *somewhere*, but you need to do some actual work to present it in a
>>> reasonable fashion.
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Mon, 30 Mar 2026 12:02:52 -0700
>>> From: Adrian Johnston <ajohnston4536_at_[hidden]>
>>> To: std-proposals_at_[hidden]
>>> Subject: Re: [std-proposals] Benchmarking contract evaluation
>>> semantics mode "assume" in Eigen.
>>> Message-ID:
>>> <
>>> CAMmHLw3LZVSQrLLJYhhLH3PQY9mBSwvcbmFwZdC3sb8iMkgrDw_at_[hidden]>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> That was a very well written paper. And in all honesty, it looks like I
>>> am
>>> barking up the wrong tree on this one at this point.
>>>
>>> As an anecdote, and a total aside, this isn't the first time I have found
>>> myself discussing "defense in depth" with someone from Microsoft. The
>>> last
>>> time, we were trying to build those AI powered glasses Zuckerberg has
>>> spent
>>> so much money on. I actually don't know if the current iteration even has
>>> an operating system, with which to implement "defense in depth" layers. A
>>> fixed function application running on a few microcontrollers held
>>> together
>>> with glue and tape is different than a compiler or an OS.
>>>
>>> Thanks for the paper, clearly you have put a lot more thought and
>>> research
>>> into this than I have.
>>>
>>>
>>>
>>> On Mon, Mar 30, 2026 at 4:07?AM David Brown via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>> > On 29/03/2026 12:42, Jonathan Wakely via Std-Proposals wrote:
>>> > >
>>> > >
>>> > > The appropriate uses of assume are different from the appropriate
>>> uses
>>> > > of assertions. They are not two sides of the same coin.
>>> > >
>>> > > See
>>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2064r0.pdf
>>> > > <
>>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2064r0.pdf>
>>> > >
>>> > > Assertions should be used liberally and at API boundaries.
>>> Assumptions
>>> > > should be used carefully based on profiling and measurement of where
>>> > > they improve codegen, not just spammed in place of all assertions.
>>> > >
>>> > >
>>> >
>>> > I don't really agree with the distinctions made in that paper. But
>>> > perhaps that is just my background and the kind of programming I do.
>>> > The standards must be general, and must err on the side of conservative
>>> > choices. However, I think it is important to understand there are
>>> > different viewpoints here, and different needs.
>>> >
>>> > To me, it is a natural thing that a function has a pre-condition and a
>>> > post-condition. The caller guarantees that the pre-condition is
>>> > fulfilled. The function can assume that the pre-condition is
>>> fulfilled,
>>> > and uses that to ensure the post-condition is fulfilled. The caller
>>> can
>>> > then assume that the post-condition is fulfilled. That is the whole
>>> > point of the process - it is what gives meaning to programming. A
>>> > "function" is something that, given suitable inputs, produces suitable
>>> > outputs. (To handle side-effects, we can pretend that "the world
>>> before
>>> > the call" is an input and "the world after the call" is an output.
>>> That
>>> > is not very practical for writing pre and post conditions in C++, but
>>> > it's fine for talking about the theory.)
>>> >
>>> > I am hugely in favour of being able to have the language (compiler,
>>> > run-time support, etc.) check for correctness at compile time, as much
>>> > as practically possible. For run-time checks, a balance must always be
>>> > found - it is good that it is easy for the programmer to enable checks,
>>> > but also important that checks can be disabled easily. For a lot of
>>> C++
>>> > code, efficiency is not particularly important - but for some code it
>>> is
>>> > vital. So having compiler options (standardised where possible and
>>> > practical) to modify these balances is a good idea. Even the best
>>> > programmers make mistakes, and tools that help find these mistakes are
>>> > always helpful.
>>> >
>>> > However, I feel that a lot of the discussions about contracts is
>>> putting
>>> > things in the wrong place, and misunderstanding what such function
>>> > specifications mean in different places. In particular, it is about
>>> > responsibilities.
>>> >
>>> > The pre-condition of a function specifies the caller's responsibility.
>>> > The p2064 paper says the function cannot assume the pre-condition is
>>> > correct, because it is code written by someone else that determines if
>>> > it holds. It is, IMHO, precisely because the code is written by
>>> someone
>>> > else that the function author should be able to assume the
>>> pre-condition
>>> > holds. It is not their job to get the function inputs correct. It is
>>> > not the function author's job to hand-hold the caller, or figure out if
>>> > the caller has done a good job or not. It is not the job of the hammer
>>> > to determine if the user is likely to hit their thumb rather than the
>>> > nail - or if the user is trying to hammer in a screw. The function
>>> > author should be free to assume the pre-condition holds - likewise, the
>>> > compiler optimiser can assume it holds true.
>>> >
>>> > On the caller side, it is the caller author's job to make sure the
>>> > pre-condition is fulfilled. If it needs to be checked at run-time (and
>>> > such checks can be vital in development and debugging, and often worth
>>> > the cost even in final releases) then it should be done on the caller
>>> > side. After all, if the pre-condition is not satisfied, it is the
>>> > caller code that is wrong - not the function implementation.
>>> >
>>> > The inverse applies to the post-condition. The caller code can assume
>>> > the post-condition is true (unless the caller has messed up and not
>>> > satisfied the pre-condition). The function implementation is
>>> > responsible for satisfying the post-condition, and therefore any checks
>>> > should be done at that point.
>>> >
>>> > Getting this wrong is a waste of everyone's time. It is a waste of the
>>> > developer's time, whether they are implementing the caller or the
>>> > callee. It is a waste of run-time at both sides. It can ruin the
>>> > analysability of code. Suppose you have this function :
>>> >
>>> > double square_root(double x)
>>> > pre (x >= 0)
>>> > post (y : abs(y * y - x) < 0.001);
>>> >
>>> > When treated correctly, this is a pure function. There are no
>>> > side-effects. It is a complete function - it gives a correct result
>>> for
>>> > any valid input. There are no exceptions. Implementations can be
>>> > efficient, calls can be optimised (such as moving it around other code,
>>> > eliminating duplicates, compile-time pre-calculation, etc.).
>>> > Correctness analysis by tools or humans is straightforward, both for
>>> the
>>> > function itself and for caller code. There is no undefined behaviour
>>> in
>>> > the function - a call to "square_root(-1)" is undefined behaviour in
>>> the
>>> > caller.
>>> >
>>> > But if the implementation cannot assume the pre-condition is true, this
>>> > is all gone. At best, you now have UB in the function, because you
>>> have
>>> > declared that it is possible to call the function with a negative
>>> input.
>>> > At worst, the function implementation now comes with a check leading
>>> > to a logging message, program termination, a thrown exception, or some
>>> > other such effect. Now the function implementer has to think about how
>>> > to handle incompetent callers. Callers have to think about how the
>>> > function interacts with other aspects of the code - the function may
>>> > crash the program, or interact badly with threading.
>>> >
>>> > If the function implementer cannot trust code to call it correctly, and
>>> > function callers cannot trust function implementers to code correctly,
>>> > then the whole concept of programming falls apart. Every function
>>> > becomes a paranoid code snippet that must double-check and triple-check
>>> > everything, including the function calls used to check the function
>>> calls.
>>> >
>>> >
>>> > There are, of course, points in code where you do not trust others.
>>> You
>>> > don't trust data coming in from outside. You don't trust caller inputs
>>> > at API boundaries, at least for "major" functions or where the
>>> > consequences of errors can be significant. But if you can't trust code
>>> > internal code and function calls, everything falls apart.
>>> >
>>> > And if "pre" and "post", along with contract assertions, cannot be
>>> > assumed to be satisfied (without optional checks to aid debugging),
>>> then
>>> > they are IMHO pointless in almost all code. I would prefer to be able
>>> > to add these freely in all sorts of code, even when I control both
>>> > caller and callee - specifications written in C++ are preferable to
>>> > specifications written as comments. I had hoped that C++26 contracts
>>> > would let me write clearer code, have better static checking, have
>>> > optional run-time checking on chosen functions while debugging, and
>>> lead
>>> > to more efficient generated code. I had hoped it would lead to
>>> > programmers being clearer about their responsibilities - focusing more
>>> > on getting their own code right, rather than how they should deal with
>>> > other people's mistakes.
>>> >
>>> > C++ is, of course, a language designed for the needs of a huge number
>>> of
>>> > programmers with a huge variety of needs and wants - any single
>>> > developer is going to have things they like and things they dislike
>>> > about it. But I do wonder if contracts, assertions and assumptions
>>> have
>>> > hit the best balance here.
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Std-Proposals mailing list
>>> > Std-Proposals_at_[hidden]
>>> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>> >
>>> -------------- next part --------------
>>> HTML attachment scrubbed and removed
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>>
>>> ------------------------------
>>>
>>> End of Std-Proposals Digest, Vol 84, Issue 37
>>> *********************************************
>>>
>>