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

[Sean Silva]

Hi Daniel,

It seems really counterproductive for the author of a formatting tool to
argue with his users about their style choices (even to the point of
arguing about leaving pointer initialized/uninitialized). Much better to
work on coming up with a design that can support their use case.

Maybe a possible solution is to move to a design where --detect-style is
the primary way of generating config files and a style is a richer and more
customizable notion than just an ad-hoc set of hard-coded flags (that
interact in ad-hoc ways and each constitute a sizeable maintenance burden).

In fact, I think that getting to the bottom of what constitutes a "style"
(and some general way to represent that) is probably half the battle. This
is like what Knuth had to do when designing TeX (devising the boxes and
glue model for representing page layout). The boxes and glue model is
probably fairly close to what clang-format needs, although clang-format
needs some sort of external declarative rule-based way to specify where and
what kind of "glue" needs to be inserted; "boxes" would likely be formed by
the pseudo-C++ parser. clang-format also has a more context-sensitive
aspect, which could be addressed by using the underlying pseudo-C++ parser
to inject "annotation tokens" into the token stream (e.g. "starting
template parameter list" could be an annotation token) or maintain a stack
of "contexts" (e.g. "inside template parameter list" could be a context),
that can then play a role in rule-matching. Also, there's the added wrinkle
of designing it in such a way that there is a tractable way to optimize it
to match a given style.



In a large number of cases, even a single deviation from the local coding
style is likely to fully block adoption of clang-format. It's a classic
catch-22: if they knew how great clang-format would be for their codebase,
then they would probably be willing to go through the politics to change
some small aspect of the company/project/game studio coding style, but
without having a critical mass of developers using it, it's unlikely that
anybody will jump through those hoops to appease a new tool, but if
clang-format doesn't comply with their coding standard, nobody can really
start using it fully (they always have to check if it gets it right and fix
where it messes things up, which sort of defeats the purpose), etc..

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131204/bb6742a5/attachment.html>