[PATCH] D31635: [clang-format] Added ReferenceAlignmentStyle option

Stephan T. Lavavej via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 14 17:26:10 PDT 2020


STL_MSFT added a comment.

> For me the biggest reason I've seen is that the gcc STL seems to be left align reference and right align pointer, I'm not 100% sure if this is deliberate,
> I wonder if this is why @STL_MSFT is keen, as MS stl is clang-formatted, but if we don't support this then comparing the MS stl to the gcc stl would be made harder.

No, it's just a stylistic preference on my part. (I avoid looking at GCC's libstdc++, but reference/pointer alignment is a raindrop in the vast ocean of differences between our implementations.)

My ideal preference is left-aligned references and middle-aligned pointers. This is because I think of the reference as inherently modifying the type, i.e. `const int&` as a cohesive unit, instead of the referenceness "belonging" to the variable. For pointers, given the choice between `const int* ptr` and `const int *ptr`, I prefer left-align for the same reason (`ptr` is a variable of type `const int*`, I never think of `const int` being the type of `*ptr` although that is historically how C syntax was viewed, as I understand it). That's what we've chosen for production code right now due to clang-format's limited configuration. However, because pointers exist as separate objects in memory, where const can be applied to both levels (unlike references), I most prefer middle-alignment: `const int * const ptr` (or `int const * const ptr`).

The limited configurability of clang-format is definitely an adoption blocker, and we had to live with several stylistic changes that weren't quite what we preferred, when we converted our codebase over. Given that opinions on the placement of references and pointers do vary, it seems reasonable to add such configuration to clang-format.


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

https://reviews.llvm.org/D31635



More information about the llvm-commits mailing list