While GCC makes it non-experimental for some time when will libc++ start moving it to non-experimental? Also, I am wondering whether it is mature enough for application development.
We are working on it (see ⚙ D89057 Add the C++17 <memory_resource> header (mono-patch)). Maybe we will get it done in the LLVM15 time frame. I’m quite confident that we will have it in LLVM16 if we don’t get it in LLVM15. We don’t provide many guarantees for the
experimental features, so you probably shouldn’t use them in production. (i.e. neither API nor ABI stability are guaranteed)
I’m sorry if this is a silly question but isn’t the API particularly guaranteed by the C++ standard?
Only the API in the
std namespace is guaranteed by the standard. Everything inside
std::experimental is part of an IS. The IS may change the API and there might be differences between the API inside
std::experimental. I don’t think there are any differences between the two in this case, but I don’t know.
Do you mean TS?
I don’t think there are any differences between the two in this case, but I don’t know.
There is no
std::resource_adaptor in C++17, and
std::polymorphic_allocator has some new members added in C++20 and a default template argument, which were not present in
Do you mean TS?
Oops, yes that’s what I meant.
There is no
std::resource_adaptorin C++17, and
std::polymorphic_allocatorhas some new members added in C++20 and a default template argument, which were not present in
Interesting, I didn’t know that. Thanks!
I really want to see this feature sooner. I wonder how usable the experimental version would be for prototyping.
On the other hand for production there are a bunch of C++20/23 features which are way more important to me to see in Xcode as soon as possible - ranges, coro, expected. Especially that Xcode doesn’t get the latest Clang feautures quickly.
I saw somewhere that there was a plan to replace Apple Clang in Xcode with upstream LLVM but there isn’t any news since then.
Is there a roadmap for LLVM 15, 16? Thanks for your work!
No, there is no roadmap. Most of the work on libc++ is voluntary, so it’s mostly what people feel like implementing. If you want to get the features earlier feel free to contribute a few patches . For
std::pmr you’ll have to wait a bit longer. It’s just really large.
As @philnik said there’s no roadmap. The team working on libc++ is quite small so it will take some time for us to implement all C++20/C++23 features.
Coro should be done.
Ranges is being worked on, but it’s large so it will take some time before it’s done.
I’m not aware of anybody working on
std::expected, but that’s been voted in quite recently. (It might even make sense to wait for the P2505: Monadic Functions for std::expected to land before starting to implement it.)
Of course you’re welcome to aid us and implement things in libc++ you care about.
std::expected I’ve actually got ⚙ D124516 [libc++][WIP] Implement P0323R12 (expected), but the implementation doesn’t work properly because clang doesn’t support Conditionally Trivial Special Member Functions currently and I think it’s a lot more work to implement all of them in base classes (and a lot uglier) than it’s worth.
I missed that review. If waiting for Clang results in cleaner code I prefer to wait for Clang support.
std::expected isn’t supported on Clang for the same reason. I’m not going to jump through hoops to implement a C++23 library feature without using C++20 language features, so it’s gated by:
#if __cplusplus > 202002L && __cpp_concepts >= 202002L
Thanks for the invitation and thank you for your contribution! I’ve been following the development recently and trying to understand what’s going on in the development process.
I’m lucky to work on production code limited by just what Xcode is providing.
I think P0848 is resolved https://github.com/llvm/llvm-project/commit/21eb1af469c3257606aec2270d544e0e8ecf77b2
I noticed that microsoft’s implementation is using deducing this and I wonder if it is a convenience feature or a requirement too.
Well ⚙ D128619 [Clang] Implement P0848 (Conditionally Trivial Special Member Functions) I was too rush.
std::expected? It’s just a convenience, so you don’t have to define four overloads of
FWIW, we’re no longer using explicit object member functions for
std::expected; STL couldn’t stomach the necessary C-style cast without which the feature is not fit for purpose.
I found that in libc++, std::pmr::monotonic_buffer_resource is not implemented yet. Am I correct?
Yes, that’s correct.
Then, they will be kept in the experimental namespace for a while.