Thank you for this insightful breakdown of performance enhancement approaches in C++. Your analysis of the three pathways is quite illuminating.

Regarding option A, our semantic library aligns closely with this philosophy by providing high-level abstractions for stream processing while maintaining optimisation potential. The library's design allows for lazy evaluation and parallel execution strategies similar to std::execution, but with additional temporal semantics for time-series data.

Option B represents an interesting direction, though as you rightly note, the trade-offs in abstraction guarantees make it challenging for general adoption. Our approach has been to work within the current language model while exploring how far we can push optimisation through template metaprogramming and clever scheduling.

The primitive-based approach (C) is particularly relevant to our thread pool implementation, where we use std::atomic and other low-level constructs to build higher-level abstractions without sacrificing performance.

What's your perspective on how these approaches might converge in future C++ standards? Particularly, do you see potential for standardising some of the stream processing patterns we've implemented in semantic, perhaps with better compiler integration?

Yours sincerely,
Eloy Kim

»ñÈ¡Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, December 16, 2025 10:48:23 PM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Sebastian Wittmeier <wittmeier_at_[hidden]>
Subject: Re: [std-proposals] : Re: [PXXXXR0] Add a New Keyword ¡®undecl¡¯


Generally speaking there are 3 ways to get those performance enhancements into C++:



A) With C++ constructs that provide streams and other conceptual classes and functions and the implementations optimize those for maximum performance. You mentioned std::execution as an example of such an approach



B) Directly into the C++ language and abstract machine. You allow ending local lifetimes early or even more explicit control over storage location or execution ordering. That is powerful, but also gives up many guarantees and abstractions (or freedoms for the compilers and optimizers) and as simple as it sounds, would be the most difficult and meet the most resistance or highest bar for inclusion.



C) With primitives, which are a bit higher than intrinsics, but lower than A) and less general than B). In current C++ one could count std::atomic<> into this class. Compared to B) it is limited to a specific type (template). Compared to A) it is lower-level.


-----Urspr¨¹ngliche Nachricht-----
Von: Kim Eloy <eloy.kim_at_[hidden]>
Gesendet: Di 16.12.2025 15:02
Betreff: Re: [std-proposals] : Re: [PXXXXR0] Add a New Keyword ¡®undecl¡¯
An: std-proposals_at_[hidden]; SD SH <Z5515zwy_at_[hidden]>;
CC: Sebastian Wittmeier <wittmeier_at_[hidden]>;
Thank you for the insightful discussion on performance, object lifetimes, and compiler optimisations. Reading the exchange prompted a thought regarding higher-level abstractions that could benefit from, and provide concrete use cases for, the low-level mechanisms under consideration.

The conversation centres on enabling more efficient memory reuse and locality by giving programmers finer control over an object's storage duration. This is a powerful capability. It strikes me that one family of abstractions that could leverage such control effectively is the domain of stateful stream processing¡ªcommon in financial systems, IoT, and event-driven applications. In these domains, data arrives as a continuous flow, and processing often involves windowing, temporal joins, and stateful aggregation. The performance there depends not just on algorithmic efficiency but critically on managing the lifecycle of intermediate state and buffers to minimise allocations and maximise cache locality.

My own work in this area led to
"semantic-cpp", a header-only library for C++17. Its design was driven by the need to process ordered sequences¡ªlike market data feeds or sensor readings¡ªwith a focus on temporal awareness and minimal overhead. A core concept is that every element carries a signed temporal index, enabling native support for sliding/tumbling windows and time-aware operations. More pertinent to this discussion, its streams are lazy until materialised (e.g., via
".toWindow()" or
".toStatistics()"), and it is deliberately "post-terminal," allowing operations to continue after a reduction. This model naturally encourages patterns where intermediate state has clear, scoped lifetimes, which could align well with proposals for more explicit lifetime control.

While the library currently achieves performance through standard C++17 means, the kind of optimisations you are discussing¡ªwhere overlapping or complex lifetimes hinder memory reuse¡ªcould significantly benefit such abstractions. For instance, if a compiler could more aggressively reuse memory for the intermediate state in a chain of windowed operations, based on clear programmer hints or scope annotations, it would elevate the efficiency ceiling for these high-level patterns.

Perhaps the broader question is whether the standard library's future might encompass more sophisticated data-flow or stream-composition abstractions. If so, the low-level mechanisms for lifetime optimisation being debated now would be a critical foundation. Libraries like
"semantic-cpp" (or similar concepts in proposals like
"std::execution") could serve as concrete test cases for how well those foundations support real-world, stateful streaming workloads.

I appreciate your time and the valuable technical discussion.