klimek added a comment. In D69764#2934686 <https://reviews.llvm.org/D69764#2934686>, @aaron.ballman wrote:
> 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. Happy to go the RFC route if @MyDeveloperDay wants to do that. FWIW, I don't understand the idea of the community being a democracy. It is not, and never was. Chris has designed an escalation process, when this was raised to him - I don't know whether this was ever made official or tested. I also don't see this as a big change from clang-format's principles - C++ is (unfortunately) way too complex to not be able to introduce subtle bugs - the history of clang-format is full of them. Note that I don't think the change will get consensus on an RFC, but not making the change will not get consensus, either - in that case, other than escalating to a clear higher decision power, or letting main contributors make the call, I don't know what to do. 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
