<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 10, 2018, at 13:28, Marshall Clow 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=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jul 26, 2018 at 9:20 PM, Eric Fiselier via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote><div class=""><br class=""></div><div class=""><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">[I have had discussions with several people, and I'm attempting to summarize here]</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class=""><br class=""></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">Due to factors beyond our control, I do not believe that we can provide a version of std::filesystem and promise future ABI stability at this time.</div><br class="gmail-Apple-interchange-newline">More information:</div><div class=""><br class=""></div><div class="">* The features for caching directory information were added late in the C++17 cycle, and there have been some concerns about them.</div><div class="">LWG issue #2708 (<a href="https://wg21.link/lwg2708" class="">https://wg21.link/lwg2708</a>) is one of them, and there are a couple of upcoming papers about the same part of the standard.</div><div class=""><br class=""></div><div class="">* The clock stuff being added in C++20 has already been discussed here.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">We can:</div><div class=""><br class=""></div><div class="">1) Not ship std::filesystem, shipping only std::experimental::filesystem.</div><div class="">I think that this is a disservice to our users; because people are asking for std::filesystem, and other vendors are providing it.</div><div class="">Note: experimental::filesystem is *different* from std::filesystem, and they're only going to diverge further. In an ideal world, we would have two implementations; one for experimental::filesystem, and the other for std::filesystem, and they would behave differently (each according to their specification)</div><div class=""><br class=""></div><div class="">2) Ship std::filesystem as it is, as part of libc++.dylib.<br class=""></div><div class="">I don't think that this is a viable option, given that we are pretty sure (certain) that ABI changes are coming down the pike.</div><div class=""><br class=""></div><div class="">3) We can ship std::filesystem as a static library; marked as "not ABI stable"</div><div class="">We can put it into the libc++ dylib once we’re confident that we can provide a stable ABI.</div></div></div></div></div></blockquote><div><br class=""></div><div>After talking to Marshall and Eric, I believe 3) is OK and I take back my objection to shipping a non-experimental filesystem in LLVM 7. The main reasons are:</div><div><br class=""></div><div><div class="">- We’re forcing users to link manually with -lc++fs. This forces them to read the documentation, which contains a fat warning about ABI stability.</div><div class="">- This is what GCC and MS have done — it’s easier if we stay aligned with them.</div><div class="">- Since we’re shipping c++fs as a static library, the only potential problem is that users will use ABI-unstable types in their own ABIs. We’re not going to break the symbols exported from libc++.dylib at all.</div><div class="">- Filesystem is in an inline namespace __fs, so we can decide to bump that inline namespace if we break the ABI. This will cause users that may have leaked filesystem types in their ABIs to get clear link errors when we change the ABI.</div><div class=""><br class=""></div><div class="">So I think 3), which is the status quo, is fine.</div><div class=""><br class=""></div><div class="">Louis</div><div class=""><br class=""></div></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">Note: libstdc++ has done exactly this.<div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">See <a href="https://www.reddit.com/r/cpp/comments/789g99/gcc_lands_support_for_c_filesystem_ts/" class="">https://www.reddit.com/r/cpp/comments/789g99/gcc_lands_support_for_c_filesystem_ts/</a> for a discussion of this approach.</div><br class="gmail-Apple-interchange-newline"></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">People can use std::filesystem, and include the object code it in their executables, and when the ABI changes, they will be affected at build time, not at run time. The downside is that they will have to re-build to get bug fixes.</div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class=""><br class=""></div><div style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial" class="">-- Marshall</div><br class=""></div><div class="">P.S. I admit that this is not the best of all possible worlds.</div><div class=""><br class=""></div></div></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=""></body></html>