Date: Tue, 31 Mar 2026 01:34:38 +0500
I added an abstract section and some new points at the end, while using
aliases to simplify the deque and vector specializations.
On Tue, Mar 31, 2026 at 1:12 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 42 (Muneem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 Mar 2026 01:12:19 +0500
> From: Muneem <itfllow123_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 84, Issue 42
> Message-ID:
> <CAMREwHekCYXC0kj95MqNY5xKfYfM0LQgeFzNiF=
> S202+VtLJhg_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> > *********************************************
> >
> -------------- 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 43
> *********************************************
>
aliases to simplify the deque and vector specializations.
On Tue, Mar 31, 2026 at 1:12 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 42 (Muneem)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 31 Mar 2026 01:12:19 +0500
> From: Muneem <itfllow123_at_[hidden]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 84, Issue 42
> Message-ID:
> <CAMREwHekCYXC0kj95MqNY5xKfYfM0LQgeFzNiF=
> S202+VtLJhg_at_[hidden]>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> > *********************************************
> >
> -------------- 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 43
> *********************************************
>
Received on 2026-03-30 20:34:58