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