search for: r338093

...as currently included in the release branch for LLVM 7? If that is correct, then we can either (1) define file_time_type in a way that is forward-ABI-compatible with the definition that will be used in C++20 and patch LLVM 7 accordingly (2) do nothing and live with an ABI break in C++20 (3) revert r338093 (and perhaps some patches that depend on it) in the LLVM 7 branch, and keep shipping Filesystem as being experimental (1) is ideal, but we have to confirm that my understanding is correct AND agree on a fix, soon. (2) is a no-go. (3) is the safest and simplest option. If we can't get a soluti...

...7? >> >> If that is correct, then we can either >> (1) define file_time_type in a way that is forward-ABI-compatible with >> the definition that will be used in C++20 and patch LLVM 7 accordingly >> (2) do nothing and live with an ABI break in C++20 >> (3) revert r338093 (and perhaps some patches that depend on it) in the >> LLVM 7 branch, and keep shipping Filesystem as being experimental >> >> (1) is ideal, but we have to confirm that my understanding is correct AND >> agree on a fix, soon. >> (2) is a no-go. >> (3) is the safe...

FWIW, I’d like for us to come to an agreement before the branch for LLVM 7.0 is cut. How do others feel about this? Am I wrong when I claim that shipping an ABI-unstable feature in the std:: namespace is a deviation from normal practice? Am I overcautious when I say it’s asking for trouble? Eric, I know you’re busy and may not have time to do the work so I’m totally willing to chime in, but I’d