papers

Yes, reading the actual data would still be UB. Hopefully will be fixed in C++29: https://github.com/cplusplus/papers/issues/592

I believe C++26 now allows _ as a placeholder name [0]: > We propose that when_ is used as the identifier for the declaration of a variable, non static class member variable, lambda capture or structured binding. the introduced name is implicitly given the [[maybe_unused]] attribute. > In contexts where the grammar expects a pattern matching pattern,_ represents the wildcard pattern. Some of the finer details (e.g., effect on lifetime and whether a _ variable can be used) differ, though. [0]: https://github.com/cplusplus/papers/issues/878

The interpretation is probably up for some debate especially since meeting details are not public, but some relevant links are: - The P3390R0 Safe C++ proposal and the related vote in the 2024-11 Wrocław meeting: https://github.com/cplusplus/papers/issues/2045 - The adoption of the paper P3466 R1 (Re)affirm design principles for future C++ evolution at the same meeting, which contains language which can be interpreted as preemptively foreclosing a Safe C++-style approach: https://github.com/cplusplus/papers/issues/2121

And yet, there is a good chance that C++ will start doing exactly this [1]. Because [2]: > The performance impact is negligible (less that 0.5% regression) to slightly positive (that is, some code gets faster by up to 1%). The code size impact is negligible (smaller than 0.5%). Compile-time regressions are negligible. Were overheads to matter for particular coding patterns, compilers would be able to obviate most of them. > The only significant performance/code regressions are when code has very large automatic storage duration objects. We provide an attribute to opt-out of zero-initialization of objects of automatic storage duration. We then expect that programmer can audit their code for this attribute, and ensure that the unsafe subset of C++ is used in a safe manner. > This change was not possible 30 years ago because optimizations si

For whatever its worth, if we wait long enough C++ will include the equivalent of `malloc_good_size`. https://github.com/cplusplus/papers/issues/18

https://github.com/cplusplus/papers/issues/1668#issuecomment... Looks like it did very well in St. Louis!

It is slowly making its way through the standards committee. https://github.com/cplusplus/papers/issues/43 The author has a fork of clang and gcc with some pretty impressive speedups, so I’m hopeful! https://lists.isocpp.org/sg14/2024/04/1127.php

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884 Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20... > The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code). Additionally, > Another problem is formatting of Unicode text: > std::cout << "Привет, κόσμος!"; > If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631 (I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

There was an attempt to bring this to C++ but it ran into some roadblocks https://github.com/cplusplus/papers/issues/631

Never say never, there is P2656. We'll see! It's more about making things interoperable than mandating a new tool, but it's still something useful in this space. It also links to previous work. https://github.com/cplusplus/papers/issues/1323

GitHub would not be relevant in this respect because: * It's owned by a (single) commercial corporation, Microsoft. * There is censorship both by content and in some respects by country of origin. * The code is closed. but otherwise it's an interesting idea. The C++ standardization committee uses GitHub to track papers submitted to them, see: https://github.com/cplusplus/papers

You subscribe to the Github issue of the proposal: https://github.com/cplusplus/papers/issues

This was not the reasons cited in the actual votes to postpone https://github.com/cplusplus/papers/issues/631#issuecomment-... Not that that means you're strictly wrong, mind you, just that only textual inclusion issues and template issues were voted on as being blocking at that time.