LLVM Clang 17 Adds Initial C++26 Compile Flags With -std=c++26

[phoronix]

Phoronix: LLVM Clang 17 Adds Initial C++26 Compile Flags With -std=c++26

With LLVM Clang's C++23 support coming together and the -std=c++23 option now exposed, LLVM Clang 17 Git has already added its initial options for specifying what will be C++26 / C++2C support...

https://www.phoronix.com/news/LLVM-Clang-17-std-CPP-26-CPP2C

[rene]

.lol.

[david-nk]

C++26 already? I must say I kind of lost track of the changes beyond C++17, even though C++ is the primary programming language I work with.

[fong38]

C++26 already? I must say I kind of lost track of the changes beyond C++17, even though C++ is the primary programming language I work with.

Designated initializers from C++20 are awesome, I wonder what took so long for those to land in C++ considering C had them for ages. Otherwise yeah I'm in the same boat.

[aviallon]

C++26 already? I must say I kind of lost track of the changes beyond C++17, even though C++ is the primary programming language I work with.

Very useful reference: https://en.cppreference.com/w/cpp/20

[EvilHowl]

C++26 already? I must say I kind of lost track of the changes beyond C++17, even though C++ is the primary programming language I work with.

std::format (C++20), ranges (C++20), modules (C++20, although not ready for real-world use yet), coroutines (C++20), std:: print (C++23), std::stacktrace (C++23).

There any many, many more changes since C++17, but those are the most notable for me. You can go over cppreference to read all changes if you want.

[stompcrash]

I can't keep up with all of these changes to C++! It's quite interesting, though.

[Weasel]

std::format (C++20), ranges (C++20), modules (C++20, although not ready for real-world use yet), coroutines (C++20), std:: print (C++23), std::stacktrace (C++23).

There any many, many more changes since C++17, but those are the most notable for me. You can go over cppreference to read all changes if you want.

[[no_unique_address]] is the most important for me, it allows you to make zero-cost properties (accessors without separate get/set member functions). Syntax is like normal fields, so can be implicitly converted without changing source code. It's a bit convoluted to do, though, so having built-in support for them in the standard would be better.

[reinhard_]

Is there any substantial discussion on doing something like rust editions (version 1.70 vs edition 2021), where remove all the old bad ways of doing things which have a new safer/more-efficient counterpart, perhaps alongside their normal compatibility support model?

[Mahboi]

c++26
c++29
c++32
c++35
c++38
c++41
c++44

c++47

STOP THE MADNESS
STOP ADDING BLOAT TO THIS STUPID LANGUAGE