ldionne added a comment. In https://reviews.llvm.org/D49774#1175131, @mclow.lists wrote:
> In https://reviews.llvm.org/D49774#1175062, @ldionne wrote: > > > In https://reviews.llvm.org/D49774#1174588, @EricWF wrote: > > > > > In https://reviews.llvm.org/D49774#1174565, @mclow.lists wrote: > > > > > > > I haven't reviewed this closely, but you might want to look at > > > > http://wg21.link/P0355, where we added a `file_clock` and `file_time` > > > > types. > > > > > > > > > Thanks for the information. It doesn't look to have too much bearing on > > > this from a design standpoint. Except to note that it seems to solve > > > the streaming problem by adding explicit streaming overload for time > > > points. > > > > > > It doesn't change anything from a design standpoint, but I don't think we > > can ship something deemed stable without taking P0355 into account. That's > > because it adds `file_clock` and changes `file_time_type` to use it, which > > is an ABI break. So if we take `filesystem` out of `experimental` and ship > > it before we've actually implemented the parts of P0355 that change the > > ABI, we'll have to take an ABI break in the future. That would suck because > > this ABI break would be necessary to implement C++20 properly in a fairly > > major way. > > > Another problem (that Eric and I discussed last night) is that filesystem is > part of C++17, and `file_clock` is C++20. So we need a solution for C++17 as > well. I believe one approach here would be to define `__file_clock` in C++17 (the way it is specified in C++20), and then have `using file_clock = __file_clock` in C++20. Would this be a valid strategy? Repository: rCXX libc++ https://reviews.llvm.org/D49774 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
