I love how to do anything in this language, you have to fight it with all you have. You have to use features in ways that feel like they were probably never intended to be used in. Everything is just an accident, some random pattern randomly discovered by someone when some typo happened to compile.
This is so on-brand for C++, whether that is a blessing or curse is left up to the reader.
Let's try this:
constexpr std::vector<int> f() { return {1,2,3}; }
constinit std::vector<int> p = f(); // error
in D! const(int)[] f() { return [1,2,3]; }
immutable int[] aaa = f();
And the object file, look ma, aaa[] is statically allocated: internal:
db 001h,000h,000h,000h,002h,000h,000h,000h ;........
db 003h,000h,000h,000h,000h,000h,000h,000h ;........
__D5test63aaayAi:
db 003h,000h,000h,000h,000h,000h,000h,000h ;........
db 000h,000h,000h,000h,000h,000h,000h,000h ;........> Think of constexpr evaluation as taking place "in the compiler’s imagination."
This is a great line.
constexpr and std::execution seem like neat ideas, maybe I'll give them a shot if I build an AI harness around the compiler so it doesn't make me feel like a hopeless idiot for trying new things.
To be clear we are — in the service of speed — trying to bake data into compiled program output binaries, which is ostensibly faster because code-pages in memory when executed by CPU as instructions already have it?
Would the PMR variants of the STL datatypes be a solution here? The compiler could fill in the details of the range in question (the ro section), and give you constexprness?
C++ people are great at making problems for themselves and then solving them to no end.
This does not look like a productive way to get things done.
Okay so I hate to be that person but I'd really caution against sharing Arthur O'Dwyer's work given that they've been essentially ex-communicated from the C++ community.
https://patricia.no/2022/03/08/cppcon.html
https://patricia.no/2022/03/08/proposed-cppcon_safety__trans...
https://izzys.casa/2024/11/on-safe-cxx/