A few days ago I watched a CppCon video about C++23.
C++23 - What's In It For You?
It gives a quick glimpse at many of the new C++23 features but without going into much details.
At the end he tries to answer some questions that I would like to comment about. It probably would be more appropriate to post them on YouTube but I have my reasons for not doing that so I post them here instead.
At 52:58 there is a question about whether there will be a simple way to iterate over all the keys or all the values, independently, in a std::flat_map. The answer he gets is no
but the truth is that you can call the keys() or values() member function to get the container with all the keys or all the values. That'll make it pretty easy to iterate over all the keys or all the values if you want.
At 55:47 there is a question that essentially asks why we need std::move_only_function. Why can we not just use std::function to store a move-only callable and move it (similar to how std::vector can handle move-only types)? He doesn't know the answer. I think it has something to do with the fact that std::function uses type-earasure so it's impossible to enforce whether std::function can be copied at compile time because it would depend on the callable. Maybe it would have been possible if std::function threw an exception if you tried to copy it with a move-only callable but that has other disadvantages.
At 57:27 someone claims that the C backtrace function does not work well with static binaries on Linux and asks if std::stacktrace will work better. The answer he gets is that it should, because the standard says so. I think this is slightly incorrect, or at least misleading. The standard says it's "approximate". It could still be affected by optimization flags, the availability of debug symbols, etc. I don't think it will work "better" than anything that is already there. The advantage of std::stacktrace is that we get something standardized that uses the same API everywhere. Some people might not like this but I think it's the only way that makes sense for C++ because we don't want compilers to always generate additional debug symbols that we haven't asked for, and limit optimizations, just so that we can get perfect stacktraces if we happen to request one (it would go against the "don't pay for what you don't use" philosophy).
At 59:01 he gets a question if he knows why std::unreachable() is a function and not an attribute. He didn't have an answer but he speculated that it might have been better if it was an attribute because if you call std::unreachable at a place where you should not call it then that would lead to UB. I just want to say that that would have been the case even if it was an attribute (Edit: Unless he meant the unreachable attribute would only be usable directly in relation to if/else blocks and case labels. Not sure how that would work). Looking at the original proposal it seems like they preferred a function call syntax because attributes can't be used in expressions. Personally I don't have an opinion.