[PATCH] D151187: [doc] Add casting style preference to coding standards

Sergei Barannikov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Jun 14 08:05:12 PDT 2023


barannikov88 added a comment.

> ! In D151187#4420876 <https://reviews.llvm.org/D151187#4420876>, @aaron.ballman wrote:
>  I like that phrasing, thank you! Do others have opinions on using this wording over the existing wording?

Yup, it looks kind of redundant because at the very beginning of the coding standards it is already spelled, in bold:

> If you are extending, enhancing, or bug fixing already implemented code, use the style that is already being used so that the source is uniform and easy to follow.

And it still forbids functional style casts. I'd like them to explicitly be allowed for constructing objects, as if the type being cast to was a class.
In D152098 <https://reviews.llvm.org/D152098> I introduce a typedef MCRegUnit and use functional style cast to construct it from integer, like this:
`Val = MCRegUnit(*++I);`
This violates the suggested wording; I'm supposed to use static_cast here. But I plan to turn the typedef into a class in the future, and don't want to use static_cast for calling class' constructor, it is unnatural.
I'd also allow functional-style casts for constructing enums from integers. static_cast isn't safer here, only more noisy.
I'm fine with static_cast in all other cases, and I also support forbidding C-style casts completely.

Unfortunately, my English is too poor to suggest a wording that would take these cases into account.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D151187



More information about the llvm-commits mailing list