[libcxx-commits] [PATCH] D138307: [libc++] Remove default definition of std::char_traits

[Louis Dionne via Phabricator via libcxx-commits]

ldionne added a comment.

In D138307#3947433 <https://reviews.llvm.org/D138307#3947433>, @rnk wrote:

> Would it be reasonable to retain the default implementation of char_traits under a __config_site macro? This will provide downstream projects with a migration path that is not tightly coupled to the libc++ version. They can update libc++ and complete the migration as separate steps. The migration path can be removed over a longer time horizon, like after the next release.

I think the currently proposed approach in D138596 <https://reviews.llvm.org/D138596> handles that -- you basically get a deprecation warning that can be turned off via the usual deprecation-removal mechanism, and then roughly one year from now,  this becomes a hard error. I think this is very close to what you mention, unless I am misunderstanding something. Please let me know if D138596 <https://reviews.llvm.org/D138596> doesn't solve your problem.

> In our experience at Google, libc++ has recently made frequent breaking changes which prevent us from uprevving libc++, and oftentimes by extension, the entire LLVM toolchain. We are definitely committed and willing to rewrite code to conform to the standard, but the current pace of breakage and lack of migration paths is causing us problems, and I worry that we are just the canary hitting these issues first. I think other users will experience them later when it comes time to release.

FWIW, I completely acknowledge that we've been breaking more stuff recently. However, to provide some context, I would argue this is because we've never been making as much progress on our standards conformance, and also we've adopted a more aggressive stance with respect to catching invalid user code. Breakage induced by standards conformance is, I would argue, very difficult to avoid. Other breakage (such as this patch) is much easier to do something about.

I think another important thing to note here is that the project was not as active for some years, so folks perhaps got used to ultimate stability. Anyway, I'm all for providing reasonable migration paths when it's reasonable to do so, but the meaning of reasonable is what I expect we may have challenges agreeing on (not just you and me, but the overall LLVM/libc++ community and its downstream users).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138307/new/

https://reviews.llvm.org/D138307