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

[Chandler Carruth]

On Wed, Dec 4, 2013 at 2:45 PM, Daniel Jasper <djasper at google.com> wrote:

> @Ben:
> There simply are styles that I don't consider support-worthy. Yes, this is
> personal, but the line has to be drawn somewhere.
>

I don't think this is personal, I think it is simple pragmatism.

At the end of the day, the maintainers of clang-format (or any other clang
tool, or even clang itself) have a limited capacity to maintain the tool.
They have to prioritize and worry about the overall complexity added by a
feature against the benefit provided by that feature. So there are two ways
that I see a feature getting into any tool, clang-format or otherwise:

1) Someone presents a compelling use case that motivates the author /
maintainer of the tool to accept a patch (or even author a patch) which
adds the desired functionality. An example of such a use case for this
would be: huge open source project XYZ won't be able to use this tool
without it, but with it they would benefit hugely and some might start
using or even contributing to clang. This isn't a hypothetical: we added
support for the Linux kernel's coding styles.

2) Someone works really hard to send high quality patches to the tool, or
even to other tools and other parts of clang. They demonstrate that they
are a committed long-term developer on the project. Then they request that
they be allowed to add the feature and they take on the increased
maintenance burden attached to it.


I have looked at a decent amount of C++ code in various open source
projects and talked to a decent number of C++ developers and I have heard
roughly one of them (you Ben) advocate strongly for this style as a good
and useful thing they would like to continue to use in their codebase while
they are using clang-format. That's not enough for #1 even for a very
simple feature. I think we would need to see *some* evidence of the size of
developer community that would benefit from the feature, and that this size
is not in the small 10s of people.

The second path is clearly always an option, although it is often a
challenging route to take. FWIW, I *always* hope people take path #2: it
means the Clang community grows! It's the path that I took myself, that
Manuel, Edwin, Richard, and many other core contributors to Clang and
Clang-based tools took. It's a great path if you can take it, but it is an
expensive path.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131205/d9ef08e4/attachment.html>