<div dir="ltr">Hi all,<br><br>I'm currently implementing a clang tool to replace C style casts to C++ style casts, i.e. const/static/reinterpret_casts. I'm almost done, but I've ran into a collection of issues/questions that I'd like to raise here to make sure it's not a misunderstanding on my part. My solutions are included in each bullet point:<br><br>1. (Question) For dependent types, it is unknown whether static_cast or reinterpret_cast is appropriate for the situation, so I would like to leave that as a C-style cast in the refactor tool. Example below:<br><br>template <typename T> void foo() { int* ptr; (T*) ptr; }<br><br>If we call foo<int>, it can be a const_cast, but if we call foo<double>, it has to be a reinterpret_cast. In a situation where the user is writing library code, it won't only be relevant to the current translation unit but also for future purposes. Therefore, I propose that we leave dependent type c-style casts as they are.<br><br>2. (Issue/bug) In OperationKinds.def, there is an enum detailing casting to union types. This doesn't work in clang(nor GCC). Here's a compiler explorer MVCE: <a href="https://godbolt.org/z/rp8DDt">https://godbolt.org/z/rp8DDt</a>. The first statement is not a cast, but rather a CompoundLiteralExpr(InitListExpr(...)), and should not be treated as a cast. Here is the corresponding GCC document: <a href="https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html">https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html</a> about union casts. If CastKind::CK_ToUnion is ever encountered in my program, I will leave the C-style cast as is.<br><br>3. (Question) In general, should this tool for C++ also support OpenCL and Objective C++? Technically, const/static/reinterpret_casts exist in those languages (see <a href="https://godbolt.org/z/DEz8Rs">https://godbolt.org/z/DEz8Rs</a> for example). In my opinion, I think the casting tool should strictly adhere to C++ as the language of support and nothing more for the first iteration because different coding standards may be held for different languages(and I only have ample experience with C++). As a result, I propose that the first iteration of the casting tool be placed outside of clang-tidy as clang-tidy also supports Objective C (but not OpenCL), as seen here: <a href="https://clang.llvm.org/extra/clang-tidy/#id2">https://clang.llvm.org/extra/clang-tidy/#id2</a>. In the main driver I will explicitly check whether the program is in C++.<br><br>I'd appreciate any questions/concerns, or oversight on my part on the 3 issues above. Thanks!<br><br>Best,<br>Ray Zhang</div>