AaronBallman wrote: > I think we should only support offset in C++ (in all versions), and > clang::offset in all language mode, in case WG14 decides to be creative
We have consistently told both committees that materially diverging the preprocessor is unacceptable; I continue to believe that is the case and so I'm opposed to that suggestion unless there's a very convincing argument about why diverging is in the best interests of our users for some reason. [WG14 N3912](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3912.htm) proposes adding `offset` and has reasonable committee support for it within WG14, so we could support `offset` in both C and C++ with the semantics specified in C++, as well as `clang::offset` on the assumption that this lands in C2y. Alternatively, we could hold off on `offset` in C++ mode until WG14 adopts a follow-up to N3912 where we can be sure the semantics are the same between the languages. Given we already support `clang::offset`, there's not a huge rush. N3912 was discussed in Ottawa and there's supposed to be a follow-up paper with corrections, but none appeared before the Buzios mailing and there's only one more meeting left after that for new feature work in C before starting the CD ballot process. So neither option is risk-free or a clearly correct choice. My current preference is to support `offset` in both C and C++, and if C2y ends up without an `offset` parameter or standardizes something significantly different from what's in C++, we can live with the C++ behavior and non-conformance in C. https://github.com/llvm/llvm-project/pull/238064 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
