<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Eric,<div class=""><br class=""></div><div class="">I’m curious to know what the concerns are w.r.t. providing ABI stability for filesystem right now. What do you envision may require changing the ABI in the future?</div><div class=""><br class=""></div><div class="">I feel like taking filesystem out of experimental/ without providing the usual guarantees provided by libc++ for non-experimental code may not be a good idea, as we’ll be pretending that we support filesystem when we really only half support it. In other words, I think the number of people that will start using filesystem while _consciously_ knowing that it is ABI-unstable (and what that means) is quite small, and that is making our users a disservice.</div><div class=""><br class=""></div><div class="">Would it be possible to instead ship the parts we’re not quite sure we can keep ABI stable in the headers (with `_LIBCPP_HIDE_FROM_ABI`) for the time being, and lower them to the dylib eventually as things stabilize? This would allow us to ship filesystem with LLVM 7.0 without any compromise on the guarantees we make our users.</div><div class=""><br class=""></div><div class="">I’m curious to know what you think of this suggestion.</div><div class="">Louis</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 27, 2018, at 00:20, Eric Fiselier via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi All,<div class=""><br class=""></div><div class="">I recently committed <filesystem> to trunk. I wanted to bring attention to some quirks it currently has.</div><div class=""><br class=""></div><div class="">First, it's been put in a separate library, libc++fs, for now. Users are responsible for linking the library when they use filesystem.<br class=""><br class="">Second, it should still not be considered ABI stable. Vendors should be aware of this before shipping it. Hopefully all the standard and implementation bugs can be resolved by the next release, and we can move it into the main dylib.</div><div class=""><br class=""></div><div class="">Third, libc++experimental no longer contains the symbols for <experimental/filesystem>, which is really just <filesystem> is disguise. If you've been using <experimental/filesystem> you now need to link libc++fs instead.</div><div class=""><br class=""></div><div class="">Fourth, `<filesystem>` is technically available in C++11 and later. The implementation lives in the std::__fs::filesystem namespace, which is marked "inline" in C++17 but not before. We should consider documenting this as an extension to its use w/o C++17.</div><div class=""><br class=""></div><div class="">Happy coding,</div><div class=""><br class=""></div><div class="">/Eric<br class=""><br class="">[1] <a href="http://libcxx.llvm.org/docs/UsingLibcxx.html#using-filesystem-and-libc-fs" class="">http://libcxx.llvm.org/docs/UsingLibcxx.html#using-filesystem-and-libc-fs</a></div></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></div></body></html>