search for: d49774

Hi, My current understanding of the problem (based on https://reviews.llvm.org/D49774) is that we have a type, file_time_type, which is part of the ABI and is currently defined as std::chrono::time_point<_FileSystemClock>, where _FileSystemClock is an internal type represented using a __int128_t. However, C++20 will add a type called file_clock and redefine file_time_type to b...

...This is the reason we put > the symbols in a separate static library. > > /Eric > > On Tue, Aug 7, 2018 at 2:15 PM Louis Dionne <ldionne at apple.com> wrote: > >> Hi, >> >> My current understanding of the problem (based on >> https://reviews.llvm.org/D49774) is that we have a type, file_time_type, >> which is part of the ABI and is currently defined as >> std::chrono::time_point<_FileSystemClock>, where _FileSystemClock is an >> internal type represented using a __int128_t. However, C++20 will add a >> type called file_cl...

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