aaron.ballman added a comment. In D69764#2934612 <https://reviews.llvm.org/D69764#2934612>, @MyDeveloperDay wrote:
>> I was referring to @rsmith and @aaron.ballman (to clarify), both are >> maintainers in 'clang', the former of which is the 'superset' maintainer of >> this format project based on its directory. While Aaron is a peer-maintainer >> to this project, his contributions are immense, and his points are >> too-well-reasoned and motivated to be dismissed. > > Just so we are clear I'm not dismissing anyone opinions, @arron.ballman and I > have been going at this quite a bit both on and off list. I have huge respect > for these people, (even if the defence of my review it might not seem so). I > can't even think to emulate their contributions. > > Ideally I'd like their blessing, but alas I fear that might be beyond my > capabilities, but if there are things like the RFC that could even go some > way to potentially them seeing a way forward that is mutually beneficial so > that the door is even open a jar for this then I'm happy to try. > > If ultimately the answer is "no" then I need to understand what can be done > if anything, if that means a new tool then I'm ok with that as the > compromise. Out right dismissal, I would be very sorry to see. Here are my thoughts put in one place. 0) I like the idea of being able to format qualifier location, and I think clang-format is the tool I would reach for to perform that work .33) I wish this was generalized to handle all qualifiers rather than just `const`. (This is not a blocking wish.) .66) I wish this used "left" and "right" rather than "east" and "west" for user-facing options and documentation. (This is Very Strong wish but I won't block the patch over it.) 1. In general, I do not like the idea of my code formatting tool having opinions about the input source's existing formatting (I think valid code should remain valid). This is the area of concern causing me to ask for an RFC because I'm operating under the impression that not breaking code is (generally) the status quo for clang-format. 2. If the community consensus is that formatting can break code (blanket permission, case by case basis, whatever), I'll definitely abide by that decision. I just want it to be an explicit decision from a wider audience than people who might be following this very long-running patch. 3. The proposed opt-in nature of the check is a blessing and a curse. It alleviates some of the danger (it's not dangerous by default, you have to manually say you want it). But it doesn't eliminate the danger (code can still be broken) and it does raise the question of how often people opt into this sort of thing and whether it's worth the maintenance costs. I don't think any of us can answer those "do people opt in" questions though, so that's not a concern I think we should hold anything up over unless someone has actual data on usage of opt-in features for clang-format. I think opt-in alleviates enough of the danger that it's a worthwhile approach for this patch (and likely may be a good idea for a policy on future changes of the same kind). tl;dr: if there's an RFC and the community says "breaking changes aren't that big of a deal to us", it tips me from "against" to "in favor" for this functionality. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69764/new/ https://reviews.llvm.org/D69764 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
