<div dir="ltr"><div dir="ltr">On Fri, Aug 27, 2021 at 4:08 PM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, 27 Aug 2021 at 15:03, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> * Backwards compatibility is pursued, but can be broken in case of clear bugs<br></blockquote><div><br></div><div>Which I think is also tangential to the current RFC, and IMO should be treated in a separate discussion if necessary (this is a fundamental problem with how clang-format is designed).</div></div></div></blockquote><div><br></div><div>Is this a fundamental problem with the code structure and maintainability or with the mindset of the main developers?</div></div></div></blockquote><div><br></div><div>It's the algorithm - clang-format is a numerical optimizer of "beauty" - any small changes can lead to the numerical outputs changing slightly, which then leads to slight diffs in how code is formatted where two options were previously considered very "similarly beautiful". It's not happening super often, but it does happen.</div><div><br></div><div>I agree that we shouldn't introduce changes to formatting without good reasons, but we can't restrict changes only to bug fixes - new features can introduce changes, too.</div></div></div>