Date: Tue, 31 Mar 2026 01:12:19 +0500
The reason I believe that this is our first step for flattening multiple
switch statements is that if we use a solution as radical as new value
types that are evaluated in place at runtime, and we nest these value types
in one another, the optimizer can flatten the two branches into one. This
is exactly how multiple operators can resolve into
a single inline function call (also known as expression templates). Infact,
the legend Bjarne Stroustrup is a big fan of it in his book "The C++
programming language 4th edition". The point is that just as inline
functions were probably radical for their time, these features will be too,
but if implemented, it would revolutionize branching as we know it.
On Tue, Mar 31, 2026 at 1:02 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 41 (Muneem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 Mar 2026 01:01:43 +0500
> From: Muneem <itfllow123_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 84, Issue 41
> Message-ID:
> <
> CAMREwHfA4HMbbTzd8zKhsE5jUuYOf9RRs2qZ279ydBXej45ibw_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> I want to stress that while it was my fault not to provide properly
> formatted code, the reason behind doing so wasn't disrespect, but rather to
> make it as short as possible because I expect the standard people to be the
> top professionals of the industry, who dont have enough time to read my
> code except if they actually have some free time (for which I provided a
> github link). Sorry to everyone that I offended.
>
> On Tue, Mar 31, 2026 at 12:54?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 39 (Muneem)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 31 Mar 2026 00:53:53 +0500
> > From: Muneem <itfllow123_at_[hidden]>
> > To: std-proposals_at_[hidden]
> > Subject: Re: [std-proposals] Std-Proposals Digest, Vol 84, Issue 39
> > Message-ID:
> > <
> > CAMREwHf6DGLzeKnbV7HNkZWpn0NS-ZieN1NGUpiiyZj9uFrQEw_at_[hidden]>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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
> > > *********************************************
> > >
> > -------------- next part --------------
> > HTML attachment scrubbed and removed
> > -------------- next part --------------
> > The Problem
> > Recently, I wanted to provide users of my virtual machine with a few
> > functions to manage namespace objects of types such as
> > vector<vector<type_tag>>, deque<vector<type_tag>>, and so on. However, I
> > encountered significant issues with code repetition. For every distinct
> > operation, I had to provide a list of enumerators and functions that
> > implemented that specific notion across multiple other categories.
> >
> > For example:
> > To implement "pushing," I used enums like push_to_vector, push_to_deque,
> > etc. I then had to provide multiple operations based on these enums:
> > void push_multiple_to_container(const std::string string_to_read_from,
> > std::string::size_type* pos) {
> > switch(static_cast<where_to_push_enum>(
> >
> >
> absolute_base::read_from_string<get_integer_for_size<sizeof(where_to_push_enum)>>))
> > {
> > case push_to_vector:
> > implementation_template_function_f(vector,
> > read_content_to_push);
> > break;
> > case push_to_deque:
> > implementation_template_function_f(deque,
> > read_content_to_push);
> > break;
> > // ... and so on
> > }
> > }
> > This resulted in a "push_single_to_container" function and many others
> > following the same repetitive pattern. You can see the extent of this
> issue
> > in my source code here:
> >
> https://github.com/HjaldrKhilji/The-Turing-virtual-machine/blob/main/Output_modules/src/helper_option_templates_for_arithmetic_related_options.cpp
> > .
> >
> > The core issue is the repetition of the switch statement. A simple and
> > obvious fix would be to create a base class providing a virtual call(Func
> > F, Args... args) function. Derived classes would implement this by
> passing
> > the desired container type as the first argument. Using a factory
> function,
> > I could return a unique_ptr to the base class (allocated as a specific
> > derived class based on a switch statement). To implement push, pop, or
> > change operations, I would simply call the factory and use the resulting
> > pointer to pass an implementation function F to pointer->call(). A
> > conceptually similar (and perhaps better) pattern would be using
> > std::variant with a factory function and std::visit.
> >
> > However, since I am building a virtual machine where these containers act
> > as "type storage facilities for monolithically stored objects," I cannot
> > afford the overhead of virtual function calls or the new/delete cycle for
> > simple push/pop operations. I was forced to write some functions manually
> > and provide template implementations for others, naming the required
> > functions for each enum and then asking an AI to generate the rest. While
> > AI is useful, I still have to manually verify that the code isn't
> > ill-formed. Furthermore, it makes the codebase look cluttered, long, and
> > overly verbose.
> >
> > Why Single-Dispatch Polymorphism is Unsuitable for Systems Programming
> > I believe virtual functions are often impractical for systems programming
> > or game development for the following reasons:
> >
> > Cache hates me: Modern RAM has high throughput, but fetching a vtable
> > pointer can trash your cache.
> >
> > lowkey annoying Latency spikes: A cache miss when fetching a distant
> > vtable pointer can cost hundreds of CPU cycles.
> >
> > Data Locality: My goal is to keep important data close together to ensure
> > the cache stays "warm." Fetching metadata from RAM that doesn't
> contribute
> > to the computation is inefficient.
> >
> > I honestly couldn't sleep for four hours because of how messy this made
> my
> > code feel.
> >
> > Proposed Solutions:
> >
> > I propose four solutions, three of which are somewhat radical:
> >
> > The Wrapper Function (Non-Radical): Use a wrapper that takes references
> to
> > all objects, an implementation function, arguments, and the Enum class.
> It
> > would look something like this:
> > template<typename T>
> > concept IsEnum = std::is_enum_v<T>;
> >
> > template<typename... obj_t, typename IsEnum_class_name, typename
> > implementation_function, typename... func_Args>
> > return_type function_name(obj_t... objs,
> > std::initializer_list<IsEnum_class_name>, implementation_function func,
> > func_Args... args);
> >
> > This would require a language construct capable of auto-generating a
> > switch statement for the initializer_list while
> > forwarding variadic parameters. Essentially, I am proposing "inline
> switch
> > statements" that generate the branching logic
> > automatically.
> >
> > Lazy Evaluation Value Types: Provide objects with a form of dynamic
> typing
> > without vtable overhead via new expression types.
> > These would use lazy evaluation?the value isn't "realized" until an Enum
> > object is passed to it. The compiler would
> > substitute every access with the appropriate branching logic.
> >
> > Guaranteed Branching JIT Generics: Similar to C#?s JIT-compiled generics,
> > but with a catch: the branching must be guaranteed,
> > and JIT compilation should only occur if no explicit specialization
> > exists. The compiler should issue a diagnostic warning
> > regarding JIT overhead. This could revolutionize C++'s role in
> interpreted
> > languages. In fact, a partner of mine, recently
> > a German code partner wanted to use cpp for his patriotically named
> "Dutch
> > interpreter", but he had to use C#, since only
> > C# has JIT powered generics.
> >
> > API for an External tool: Provide a dedicated interface to a language or
> > tool that natively supports these specific architectural
> > features.
> >
> > Again, i tried using std::variants but they are not only ugly, but
> > impractical for a virtual machine meant to power the "next
> > generation of compilers". All I propose is a practically safe solution,
> > and the more radical and hard to implement the solution is, the more
> > practical it would be to use it. Infact this may be our first step toward
> > flattening multiple nested switch statements into one.
> >
> >
> > The Issue with AI Automation
> > Relying on AI is a matter of faith. I have to trust that every
> > transformation among thousands is correct and that every node in a
> massive
> > model is in the right state. In the context of systems architecture, it
> is
> > difficult to place that kind of faith in a purely mathematical model.
> >
> > Regards,
> > Muneem
> >
> >
> >
> >
> > ------------------------------
> >
> > 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 41
> > *********************************************
> >
> -------------- 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 42
> *********************************************
>
switch statements is that if we use a solution as radical as new value
types that are evaluated in place at runtime, and we nest these value types
in one another, the optimizer can flatten the two branches into one. This
is exactly how multiple operators can resolve into
a single inline function call (also known as expression templates). Infact,
the legend Bjarne Stroustrup is a big fan of it in his book "The C++
programming language 4th edition". The point is that just as inline
functions were probably radical for their time, these features will be too,
but if implemented, it would revolutionize branching as we know it.
On Tue, Mar 31, 2026 at 1:02 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 41 (Muneem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 Mar 2026 01:01:43 +0500
> From: Muneem <itfllow123_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 84, Issue 41
> Message-ID:
> <
> CAMREwHfA4HMbbTzd8zKhsE5jUuYOf9RRs2qZ279ydBXej45ibw_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> I want to stress that while it was my fault not to provide properly
> formatted code, the reason behind doing so wasn't disrespect, but rather to
> make it as short as possible because I expect the standard people to be the
> top professionals of the industry, who dont have enough time to read my
> code except if they actually have some free time (for which I provided a
> github link). Sorry to everyone that I offended.
>
> On Tue, Mar 31, 2026 at 12:54?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 39 (Muneem)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 31 Mar 2026 00:53:53 +0500
> > From: Muneem <itfllow123_at_[hidden]>
> > To: std-proposals_at_[hidden]
> > Subject: Re: [std-proposals] Std-Proposals Digest, Vol 84, Issue 39
> > Message-ID:
> > <
> > CAMREwHf6DGLzeKnbV7HNkZWpn0NS-ZieN1NGUpiiyZj9uFrQEw_at_[hidden]>
> > Content-Type: text/plain; charset="utf-8"
> >
> > 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
> > > *********************************************
> > >
> > -------------- next part --------------
> > HTML attachment scrubbed and removed
> > -------------- next part --------------
> > The Problem
> > Recently, I wanted to provide users of my virtual machine with a few
> > functions to manage namespace objects of types such as
> > vector<vector<type_tag>>, deque<vector<type_tag>>, and so on. However, I
> > encountered significant issues with code repetition. For every distinct
> > operation, I had to provide a list of enumerators and functions that
> > implemented that specific notion across multiple other categories.
> >
> > For example:
> > To implement "pushing," I used enums like push_to_vector, push_to_deque,
> > etc. I then had to provide multiple operations based on these enums:
> > void push_multiple_to_container(const std::string string_to_read_from,
> > std::string::size_type* pos) {
> > switch(static_cast<where_to_push_enum>(
> >
> >
> absolute_base::read_from_string<get_integer_for_size<sizeof(where_to_push_enum)>>))
> > {
> > case push_to_vector:
> > implementation_template_function_f(vector,
> > read_content_to_push);
> > break;
> > case push_to_deque:
> > implementation_template_function_f(deque,
> > read_content_to_push);
> > break;
> > // ... and so on
> > }
> > }
> > This resulted in a "push_single_to_container" function and many others
> > following the same repetitive pattern. You can see the extent of this
> issue
> > in my source code here:
> >
> https://github.com/HjaldrKhilji/The-Turing-virtual-machine/blob/main/Output_modules/src/helper_option_templates_for_arithmetic_related_options.cpp
> > .
> >
> > The core issue is the repetition of the switch statement. A simple and
> > obvious fix would be to create a base class providing a virtual call(Func
> > F, Args... args) function. Derived classes would implement this by
> passing
> > the desired container type as the first argument. Using a factory
> function,
> > I could return a unique_ptr to the base class (allocated as a specific
> > derived class based on a switch statement). To implement push, pop, or
> > change operations, I would simply call the factory and use the resulting
> > pointer to pass an implementation function F to pointer->call(). A
> > conceptually similar (and perhaps better) pattern would be using
> > std::variant with a factory function and std::visit.
> >
> > However, since I am building a virtual machine where these containers act
> > as "type storage facilities for monolithically stored objects," I cannot
> > afford the overhead of virtual function calls or the new/delete cycle for
> > simple push/pop operations. I was forced to write some functions manually
> > and provide template implementations for others, naming the required
> > functions for each enum and then asking an AI to generate the rest. While
> > AI is useful, I still have to manually verify that the code isn't
> > ill-formed. Furthermore, it makes the codebase look cluttered, long, and
> > overly verbose.
> >
> > Why Single-Dispatch Polymorphism is Unsuitable for Systems Programming
> > I believe virtual functions are often impractical for systems programming
> > or game development for the following reasons:
> >
> > Cache hates me: Modern RAM has high throughput, but fetching a vtable
> > pointer can trash your cache.
> >
> > lowkey annoying Latency spikes: A cache miss when fetching a distant
> > vtable pointer can cost hundreds of CPU cycles.
> >
> > Data Locality: My goal is to keep important data close together to ensure
> > the cache stays "warm." Fetching metadata from RAM that doesn't
> contribute
> > to the computation is inefficient.
> >
> > I honestly couldn't sleep for four hours because of how messy this made
> my
> > code feel.
> >
> > Proposed Solutions:
> >
> > I propose four solutions, three of which are somewhat radical:
> >
> > The Wrapper Function (Non-Radical): Use a wrapper that takes references
> to
> > all objects, an implementation function, arguments, and the Enum class.
> It
> > would look something like this:
> > template<typename T>
> > concept IsEnum = std::is_enum_v<T>;
> >
> > template<typename... obj_t, typename IsEnum_class_name, typename
> > implementation_function, typename... func_Args>
> > return_type function_name(obj_t... objs,
> > std::initializer_list<IsEnum_class_name>, implementation_function func,
> > func_Args... args);
> >
> > This would require a language construct capable of auto-generating a
> > switch statement for the initializer_list while
> > forwarding variadic parameters. Essentially, I am proposing "inline
> switch
> > statements" that generate the branching logic
> > automatically.
> >
> > Lazy Evaluation Value Types: Provide objects with a form of dynamic
> typing
> > without vtable overhead via new expression types.
> > These would use lazy evaluation?the value isn't "realized" until an Enum
> > object is passed to it. The compiler would
> > substitute every access with the appropriate branching logic.
> >
> > Guaranteed Branching JIT Generics: Similar to C#?s JIT-compiled generics,
> > but with a catch: the branching must be guaranteed,
> > and JIT compilation should only occur if no explicit specialization
> > exists. The compiler should issue a diagnostic warning
> > regarding JIT overhead. This could revolutionize C++'s role in
> interpreted
> > languages. In fact, a partner of mine, recently
> > a German code partner wanted to use cpp for his patriotically named
> "Dutch
> > interpreter", but he had to use C#, since only
> > C# has JIT powered generics.
> >
> > API for an External tool: Provide a dedicated interface to a language or
> > tool that natively supports these specific architectural
> > features.
> >
> > Again, i tried using std::variants but they are not only ugly, but
> > impractical for a virtual machine meant to power the "next
> > generation of compilers". All I propose is a practically safe solution,
> > and the more radical and hard to implement the solution is, the more
> > practical it would be to use it. Infact this may be our first step toward
> > flattening multiple nested switch statements into one.
> >
> >
> > The Issue with AI Automation
> > Relying on AI is a matter of faith. I have to trust that every
> > transformation among thousands is correct and that every node in a
> massive
> > model is in the right state. In the context of systems architecture, it
> is
> > difficult to place that kind of faith in a purely mathematical model.
> >
> > Regards,
> > Muneem
> >
> >
> >
> >
> > ------------------------------
> >
> > 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 41
> > *********************************************
> >
> -------------- 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 42
> *********************************************
>
Received on 2026-03-30 20:12:35