CLion BlogCLion 2025.3 Is Here, and It’s Epic: Faster Language Engine, Unique Constexpr Debugger, DAP Support, and Much More
#Clang #CLion #News #Releases #Clionnova #Constexpr #Cpp26 #Dap #Stm32 #Zephyrwest
Matthias Kretz | VirI wrote a #WG21 Kona 2025 trip report:
https://mattkretz.github.io/2025/11/13/WG21-Kona-2025-trip-report.html
Virtual Trip Report: WG21 Kona 2025
After the CD (committee draft) is out, WG21 is in bug fixing mode. Consider NB comments as the tickets that force us to consider a resolution and provide an answer. Such issues can either be design issues or wording issues (where wording does not match stated design intent). Besides NB comments, many library issues had been filed and prioritized independently, which led to several categorized as must/should fix before the standard is finalized.
netrom 
constexpr all the things! Since the evaluation of a constant expression never results in an erroneous behavior (EB, C++26)! (But use constexpr since C++11)
This was mentioned by many at the conference, not to forget: @DanielaKEngert, Mikhail Svetkin, and others.
@meetingcpp #cpp #cpp26 #cpp11 #meetingcpp #dev #undefined_behavior #ub #erroneous_behavior #eb
Dani (
Antifascista)@mkretz
"We violently agree" 😸
But P3802 will certainly have to wait until #cpp29 to become a portable C++ feature for apparent procedural reasons: it appeared *after* #cpp26 feature freeze, was never discussed in EWG, nor made it into a plenary vote. AFAICS, the mistake of #cpp0x will not be made again.
@mkretz
Just because some implementation *could* implement this kind of behaviour by using something along the lines of __local_ctx and by taking advantage of prospective #cpp26 features doesn't mean *it is*.
The described behaviour was quite controversial after std::source_location made it into #cpp20 . I can remember the discussions happening in the then-monthly EWG online meetings (COVID!) where the necessity of such unfamiliar properties of source_location::current() was seen vital to meet user expectations: the return value of that function depends on the *current compilation context*. I.e. compilers *must* re-evaluate the apparently pure, obviously dependency-free, immeditate (compiletime-only) function *at every occurance* in a TU where it is - possibly silently - invoked!
@DanielaKEngert Ah you're not creative enough. It's implicitly already in. Because there are functions that do this and a compiler vendor is free to implement their own __local_ctx right now. Being able to reflect on target properties is an implementation extension anyway. So any compiler implementing reflection (i.e. #cpp26) is almost there.
So if your library wants to use constexpr exceptions internally (in consteval functions) while still being usable for projects that enable `-fno-exceptions` … it seems like you can just wrap your code in:
#pragma GCC push_options
#pragma GCC optimize("exceptions")
// have fun with exceptions
#pragma GCC pop_options
😈 🙈
The real question is whether -fno-exceptions should apply to consteval-only exceptions at all.
I read https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2025/p3802r0.pdf "Poor Functions" last night. I jumped for joy! 😆 Finally, I had words for what I was thinking all this time. This __local_ctx idea puts into words what I wanted to say with regard to #FunctionMultiVersioning (https://gcc.gnu.org/wiki/FunctionMultiVersioning). I need to be able to reflect on those attributes in order to make SIMD types and functions behave correctly in the context of FMV. __local_ctx producing a std::meta::info sounds like the solution!