Re: Bikeshed discussion on name of library file for Filesystem TS

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 25 September 2014 02:38, Ed Smith-Rowland wrote:
> I've been playing with filesystem at it works swimmingly!

Oh good, thanks for the feedback!

> I think
>
> libstdc++fs.a
> is just fine really.
>
> It indicates that this is part of libstdc++.
> It's pithy and memorable.
>
> On the other hand if we think that adding libs for experimental components
> will be a thing then maybe
>
> libstdc++-exp-fs.a,
> libstdc++-exp-net.a

There is likely to be a separate library for at least the Parallelism
TS too, as it will have some non-trivial code that isn't just
templates or inline functions. I suppose libstdc++par.a would work for
that.

> On the other other hand this looks neater to me:
>
> libstdc++fs.a,
> libstdc++net.a,
> etc.

OK, one vote for keeping the current name (and from someone actually
using it, so that should count double ;-)

> I guess these would be merged into libstdc++ proper for C++17?

I think so, yes. When it's an official part of the standard it should
go in libstdc++.

The main reason for packaging it as a separate archive is that it
gives us more flexibility to change the code, which fits with the
experimental nature of a C++ TS, so we aren't stuck having to keep the
current implementation forever, retaining the same symbols in the
shared library for binary compatibility reasons. When it graduates
from namespace std::experimental to namespace std it will be time to
commit to exporting the symbols from the shared lib. By then the spec
might have changed (e.g. Marc had some good comments about path
iterators that would allow a much simpler, and maybe more efficient
design) and someone might have improved on the initial version of the
code.