You took over another subject, so I changed the subject line.     You know your library and your work better than me.   For A) The library could be put into the standard. If it is clean enough, widely used and broadly useful enough and basic enough. Even if this is all true, the important question would be, why not keep it as separate library. C++ is very selective, what is put into the standard library. More selective than other languages.   B) As B has a high bar and you worked with C++ for implementation instead of using inline assembly to get more performance than current C++ allows, B) probably is not a sensible option. You have nothing to contribute for B)   C) You are using existing primitives, but you have not defined new ones, which is either not needed or would need much more research. So you also have nothing to contribute for C).     This mailing list mostly is for more concrete proposals for the next iterations of the C++ programming language standard.   What are you proposing? It seems neither B) nor C)   > Don't you all consider to add a semantic data stream processor?   Are you proposing A) Including it into the language?   Then you would have to work out a proposal (paper) and get it through the standardization process with a target of perhaps C++32 (more realistic than C++29). And you are willing to invest time into optimizing the proposal, discussing alternative approaches in depth, formalizing everything (probably invest a lot more time than writing the library in the first place).   Are you asking the format of a proposal? E.g. look at existing papers on   https://en.cppreference.com/w/cpp/26.html (column Paper(s))   Or the chances of a streaming library to know to be included, whether you should write a paper?     -----Ursprüngliche Nachricht----- Von:Kim Eloy <eloy.kim_at_[hidden]> Gesendet:Di 16.12.2025 16:10 Betreff:Re: [std-proposals] : Re: [PXXXXR0] Add a New Keyword ‘undecl’ An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; 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