Hello All,

Today, in standard C++, the control-flow structure of a function is always statically bounded.

Even if there are multiple possible branches, all possible successor functions are known at compile-time.
For example:


function1 → function2 → function3
                    ↘ function4

Here the compiler knows that function2 can transfer control only to:

function3, or
function4.

This is a fundamental assumption behind C++:

All possible control-flow destinations are statically known, even if the choice is dynamic.

But in my case , successor is not statically bounded .

The model I’m working with looks like this:


function1 → function2 →  (next function is chosen at runtime)

At runtime, not at compile time, the program may write the address of:

function3, or
function4, or
functionN, or
any function from a dynamically created set.

In other words:

The set of possible successors is not known statically.
It is constructed at runtime and may vary extremely frequently.

This is very different from C++’s normal branching model, where all successors are part of the program’s fixed control-flow graph.

1. “Fetch-only” is indeed the wrong name

I agree.
The term brought in the wrong mental model, and it suggested architectural behavior that is not part of the proposal.

A much better framing is:

a declarative sequencing construct (a form of novel control flow)
that specifies what should run next,
without executing computation itself and without the semantics of a function call.

I’ll adopt clearer terminology going forward.

2. Why not `goto`, `longjmp`, or fibers?

Yes, the proposal tries to describe cross-function control transfer, but:

goto is intra-function only
longjmp bypasses stack frames, destroys local state, and is control-flow destructive
fibers/coroutines package execution state and resume points, not pure sequencing metadata

The key distinction is:

I am not trying to transfer execution state; I am trying to express an evaluation schedule that is constructed at runtime.

This is an important difference:

coroutines resume captured execution stacks
longjmp unwinds stacks
goto jumps within a function

But I want to express:

“Task T2 should run next, because scheduling metadata says so —
not because T2 is lexically next or a continuation of T1.”

It is closer to a runtime-constructed control-flow graph, not a call stack manipulation.

3. The 8-bit context mention was a mistake

You are absolutely right — fixed-width numbers do not belong in a proposal about abstract-machine semantics.

The correct description should be:

Tasks may optionally be annotated with small, implementation-defined context identifiers that sequencing logic can match against.

Their width, representation, and meaning would be entirely implementation-defined.

I should not have written “8-bit” and will correct that.

4. What does “declarative sequencing” actually mean?

By “declarative,” I mean:

The program provides metadata describing which task should run next,
while the implementation chooses how to realize that sequence.

So dynamic influence is allowed — and intended — but the sequencing construct itself:

does not compute
does not load or store
does not participate in side effects
only names the next evaluation target

This is separate from the execution of the tasks themselves.

5. Yes, tasks may insert new tasks into the schedule

This is central to the use case.

To answer your question:

Can a task T1 insert T5 into the schedule?

Yes — that is exactly the model.
The sequence is not fixed; it is runtime-constructed and frequently updated.

This is what distinguishes it from unrolled loops or statically generated dispatch chains.

The metadata structure effectively becomes:

a runtime-modifiable list, or
small graph, or
chain of successor relationships

built out of ordinary C++ logic.

The proposal is not about the container; it is about giving the implementation freedom to run that schedule without repeatedly routing through a dispatcher.

6. Where this differs from existing mechanisms

Today C++ implements dynamic scheduling with:


while (!q.empty()) {
    auto t = q.pop();
    t();      // ordinary function call via dispatcher
}

But this carries:

call/return overhead
mandatory ABI boundaries
loss of optimization opportunities (opaque function pointer calls)
repeated re-entry into the dispatcher

What I want to explore is whether C++ could have:

a side-effect-free construct that expresses the sequence itself
giving implementations permission to execute the sequence more directly.

This is closer to an explicit, runtime-defined control-flow path,
not a request for new hardware or new stack semantics.

Best Regards,
Kamalesh Lakkampally,

Founder & CEO

www.chipnadi.com

On Thu, Dec 4, 2025 at 6:39 PM Jens Maurer <jens.maurer@gmx.net> wrote: