Function calls, loops, conditionals, local variables, memory allocation (via new), constructors&#x2F;destructors, etc., were all there in D2007.

It has been a very exciting fifteen years. As a minor counter argument, other languages will let you run any code at compile time. Because it&#x27;s code. And it can run whenever you want. C++ has that too I suppose, you just have to weave some of your control flow through cmake.

We aren&#x27;t talking about just compile time function evaluation of ConstExpressions. C++ had that all the way back in C++11, and many compilers were doing CTFE long before that as an optimisation (but as a programmer you couldn&#x27;t really control when that would happen)Compilers are always allowed to CTFE than what the C++ standard specifies, many do. The standard is just moving the lower bar for what all compilers must now evaluate at compile time, and what c++ programmer may expect from all compilers.Since C++11, they have been massively extending the subset of the language that can be evaluated at compile time. C++14 allowed compiletime evaluation of loops and conditionals, along with local variables. C++20 allowed CTFE functions to do memory allocation (as long as it was also freed) along with calling object constructors&#x2F;deconstructors.The main new thing in C++26 is the ability to do CTFE placement new, which is something I remember missing the last time I tried to do fancy C++ stuff. Along with marking large chunks of the standard library as constexpr.

Tbf, C and C++ did constant folding for function calls since forever too (as well as pretty much any compiled language AFAIK), just not as a language feature, but as an optimizer feature:<a href="https:&#x2F;&#x2F;www.godbolt.org&#x2F;z&#x2F;Kja5jrWo5" rel="nofollow">https:&#x2F;&#x2F;www.godbolt.org&#x2F;z&#x2F;Kja5jrWo5</a>&gt;I don&#x27;t understand why it is so complex in C++Because C++ is a completely overengineered boondoggle of a language where every little change destabilizes the Jenga tower that C++ had built on top of C even more ;)

Constexpr as a keyword which slowly applies in more places over decades is technically indefensible. It has generated an astonishing quantity of work for the committee over the years though which in some sense is a win.I think there&#x27;s something in the psychology of developers that appreciates the byzantine web of stuff which looks like it will work but doesn&#x27;t.

This would make more sense if constexpr was actually constant like say, Rust&#x27;s const.The Rust const fn foo which gives back x + 42 for any x, is genuinely assured to be executed at compile time when given a constant parameter. If we modify the definition of foo so that it&#x27;s not constant the compiler rejects our code.But C++ constexpr just says &quot;Oh, this might be constant, or it might not, and, if it isn&#x27;t don&#x27;t worry about that, any constant uses will now magically fail to compile&quot;, exactly the spooky action at a distance you didn&#x27;t want.When originally conceived it served more or less the purpose you imagine, but of course people wanted to &quot;generalize&quot; it to cover cases which actually aren&#x27;t constant and so we got to where we are today.

That does work in D, has for 18 years now, and is one of D&#x27;s best loved features. Nobody has asked for the constexpr keyword.

Why? How is changing constness of foo different from changing return type of foo, or changing set of thrown exceptions, or argument set?Especially now that it is a good practice to define c++ functions like<pre><code> auto f(auto &amp;&amp;x) -&gt; decltype(1+x)

?</code></pre>

I think being explicit is a good thing in C++. Suppose there is not constexpr in C++ and the following works:<pre><code> inline int foo(int x) { return x + 42; }
 int arr[foo(1)];
</code></pre>
I think it would qualify as spooky action-at-a-distance if modifying foo causes arr to be malformed. And if they are in different libraries it restricts the ways the original function can be changed, making backwards compatibility slightly harder.

D does compile time function evaluation every time there&#x27;s a ConstExpression in the grammar. It did this back in 2007. It required no changes to the grammar or syntax, it just enhanced constant folding to be able to do function calls.I don&#x27;t understand why it is so complex in C++.

8 days ago, 90+ comments: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43775670">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43775670</a>

love seeing all the constant updates but sometimes i feel like the biggest pain points just stick around way too long - you ever feel like these standards chase the wrong problems sometimes?

GCC only started supporting C++20 modules in a usable form, last month, and there are still parts missing from C++20.So expect at very least 2026 + 5 =&gt; 2031 for that command to provide a complete C++26 development experience.

Not if you run RHEL:dnf install gcc-toolset-X

And in the wild (supported by all major compilers) we will see this somewhere around 2040…

One of my first tasks in my carrier was implementing stable sort to incomplete stl implementation. In 3 years no one used it. This so niche it should not be part of C++ standard.

seeing the words &quot;constexpr sorting&quot; makes all the compile-time sirens go off in my head

Boost.asio and Boost.cobalt both allow you to do this. You could even implement the coroutine traits yourself if you don&#x27;t want to use these libraries.

co_await etc is there, now it&#x27;s a matter of libraries picking that up.On Windows, you can do this today:<pre><code> auto response {co_await httpClient.GetStringAsync(uri)};</code></pre>

Amazing, now could I just get a way to do asynchronous network requests in two lines of code, like I have with other languages?Honestly, it seems to me like the committee is constantly chasing the easy bits but is failing to address the bigger issues in the language and, more importantly, the standard library.

C++26: more constexpr in the standard library