sammccall added a comment. For my part, I'm convinced and now +1 (or at least +0.5) on this being OK to include. In users' minds this is a formatting/style operation, and the UX of clang-format and its integrations is much better than clang-tidy.
Implementation quality problems are a risk, but can be mitigated: - today: clang-format itself is mature and enforced on some projects. And this feature isn't as mature yet, and can be dangerous. Guarding the feature as experimental by a flag and/or prefixed config names seems like a good way to tell people that. - forever: if this can never be made sufficiently robust, it should not be promoted to a "standard" feature. This would be sad/awkward, but the history of clang-format suggests it's not that likely. @MyDeveloperDay: sorry that it's been (and continues to be) hard to get consensus here. It's not surprising: there are strong arguments in both directions, and they appeal to different values. @steveire: I don't think it's true or helpful to suggest the downsides aren't real, or to isolate people as holdouts. > I think we had a really good, inclusive discussion on this change, so I don't > think an RFC would add anything to it. I agree with this. I'd be surprised if the balance of arguments about const-fixing was substantially different. A more abstract RFC about direction seems unikely to be productive. I think *all* uses of clang-format can break certain code, it's a (large) difference in degree. So the concrete details matter. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69764/new/ https://reviews.llvm.org/D69764 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
