[llvm-dev] [cfe-dev] Filesystem has Landed in Libc++

[Marshall Clow via llvm-dev]

On Thu, Jul 26, 2018 at 9:20 PM, Eric Fiselier via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi All,
>
> I recently committed <filesystem> to trunk. I wanted to bring attention to
> some quirks it currently has.
>
> First, it's been put in a separate library, libc++fs, for now. Users are
> responsible for linking the library when they use filesystem.
>
> 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.
>

[I have had discussions with several people, and I'm attempting to
summarize here]

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.

More information:

* The features for caching directory information were added late in the
C++17 cycle, and there have been some concerns about them.
LWG issue #2708 (https://wg21.link/lwg2708) is one of them, and there are a
couple of upcoming papers about the same part of the standard.

* The clock stuff being added in C++20 has already been discussed here.


We can:

1) Not ship std::filesystem, shipping only std::experimental::filesystem.
I think that this is a disservice to our users; because people are asking
for std::filesystem, and other vendors are providing it.
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)

2) Ship std::filesystem as it is, as part of libc++.dylib.
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.

3) We can ship std::filesystem as a static library; marked as "not ABI
stable"
We can put it into the libc++ dylib once we're confident that we can
provide a stable ABI.

Note: libstdc++ has done exactly this.
See
https://www.reddit.com/r/cpp/comments/789g99/gcc_lands_support_for_c_filesystem_ts/
for a discussion of this approach.

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.

-- Marshall

P.S. I admit that this is not the best of all possible worlds.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180810/da296306/attachment.html>