Requires specification in a standard (presumably CPP26/29/32, but a change in cadence or fork/alternative that is a formal standard would be acceptable) and usable by programmers in at least one open source implementation (eg gcc or clang, but something new/newly open source would qualify).
Question inspired by https://safecpp.org/ but it does not need to be this proposal or a derivative that is accepted and implemented to resolve to true.
Added: If 2027 is judged yes, so will 2030, 2033, and 2037. If 2030, also 2033 and 2037. If 2033, also 2037. I will trade.
1,000
1.00
https://izzys.casa/2024/11/on-safe-cxx/ very long post with various bits that may sway estimates of this question.
https://x.com/seanbax/status/1834435155173220802 (coauthor of proposal, person who has been working toward it for years) responding to question about how likely it is to get approved for c++26:
No chance. If the commercial conpiler vendors dove into this and we resolved the design issues and had multiple toolchains going, it could be deployed to mainstream users in 18-24 months and we could do standards work for 29. The design work has to come first.
From the proposal (presumably optimistic, if everything goes well):
Everything in this proposal took about 18 months to design and implement in Circle. With participation from industry, we could resolve the remaining design questions and in another 18 months have a language and standard library robust enough for mainstream evaluation. While Safe C++ is a large extension to the language, the cost of building new tooling is not steep. If C++ continues to go forward without a memory safety strategy, that’s because institutional users are choosing not to pursue it; it’s not because memory safe tooling is “impossible” to build.