This is my updated proposal. I hope you guys like it.

On Tue, Mar 31, 2026 at 12:26 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. Re: Std-Proposals Digest, Vol 84, Issue 37 (Muneem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 Mar 2026 00:25:59 +0500
> From: Muneem <itfllow123_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 84, Issue 37
> Message-ID:
> <CAMREwHfVod5h+hnzf09mu0B1ZLn=
> e+1HUj+1mkMxgOaPdSr40Q_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> >> *********************************************
> >>
> >
> -------------- 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 39
> *********************************************
>