Patch for clang-format to allow references and pointers to bind differently

[Ben Longbons]

On Thu, Nov 28, 2013 at 1:21 AM, Daniel Jasper <djasper at google.com> wrote:
> Well, it is also quite rare that people declare multiple uninitialized
> pointers in one line (and it would be a questionable practice).
It is extremely common. I checked both LLVM (1 thousand such
declarations, sloccount 2 million) and Linux (10 thousand / 10
million) using the following regex, which gives a few false positives
but not many:
[^/]\*.*, \*
The proportion of about 1/1000 seems to be relatively constant, and
caused by the relative lack of *need* for multiple pointers even among
the few lines of code that are declarations, rather than an aberrant
style.

> My key argument against this style would be that it suggests that "*" and
> "&" have a different binding behavior, which I don't think they have.
Sure, they don't have differences at the syntax level. But they *do*
have significantly different usage patterns.

> Well, it is not quite as easy:
> 1. I am responsible for maintaining clang-format. Ensuring that all
> combinations of options do the right thing gets significantly harder with
> more options.
I don't think this is an issue with the patch, since all of the
operations that it does now were done already, only the option checked
changed.

> 2. Need to churn through pages and pages of flag documentation to
> find the important flags makes it harder to use.
I expect that most people will either start with one of the predefined
styles, or try to go through every option...

However, it would be useful if the documentation for the two bits
linked to each other.

That said - I found the documentation for clang-format rather lacking,
since it just shows all the options in alphabetical order. It would be
better if it were separated into logical areas (indent, mandatory
lines, spaces, penalties and breaking lines) and *every* option had
examples of each possible value.

> 3. There are style choices that are bad or chosen for bad reasons. I think I
> would put this one into this category. Now, if we support that style choice
> in clang-format we ingrain it even further. If we don't (but clang-format
> still delivers good value) we might convince a few people/projects to move a
> way from this style.
Yes, my reasons were relatively weak and if I were to do it again, I
would probably do it differently - if only to avoid trouble with
formatting tools.

But it's not just an issue of forcing people to abandon their chosen
style - it's an issue of whether they use a formatter at all.

> Alp: Yes, I agree that "attach" or "align" (which astyle uses) would be
> better names for this flag. But I am waiting to resolve a few questions
> around this (e.g. there is also a request to support astyle's "middle"
> alignment). We basically have to be backwards compatible, so I'd like to
> change flags as seldomly as possible.
There is one backward-incompatibility with my patch as written: if the
user explicitly specified PointerBindsToType instead of getting it
from the BasedOnStyle.

This would actually be a good opportunity to change the name of the
option, with PointerBindsToType setting both PointerAttachToType and
ReferenceAttachToType and possibly giving a deprecation warning.

That said ... since there *will* be other options that need to be
split in the future, you need a general plan, not a specific one.


For reference, these are the options that astyle supports:
pointers: unchanged (default), type, center, value
references: like pointers (default), unchanged, type, center, value

I haven't yet tested to see what exactly astyle does for some of the
nastier cases.


Implementing infrastructure like "do everything unchanged where
possible" or "generate the config file by --detect-style" is beyond
me.

-o11c