Replying to the digest mails makes it very difficult to follow the
discussion, it's unclear which mails file replying to. The digest feature
is really good people who just want to read the mailing list and not reply.

If you want to participate in discussions, please turn off the digest
feature and reply to individual emails.



On Mon, 30 Mar 2026, 20:26 Muneem via Std-Proposals, <
std-proposals_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
>> *********************************************
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>