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
> *********************************************
>