<div dir="ltr"><div dir="ltr">On Tue, Aug 10, 2021 at 11:22 AM 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 Tue, 10 Aug 2021 at 17:43, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@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">Mixed feelings - we don't necessarily have to let users dictate the feature set, if they aren't contributing to it. Like users using -Weverything, that is ill advised and we are/should be more than happy to break them at any turn. We do get to make choices about what uses we are developing the tools for.<br></div></div></blockquote><div><br></div><div>Ah, that's not what I meant. I agree with you.</div><div><br></div><div>I meant there is a lot of potential for things that we (LLVM developers) are saying we want (in this thread) and we should pursue it without having to be bound by the "original design".</div></div></div></blockquote><div><br>Fair - though I think it's insightful to know where things started/what the goals were (& some of those are still relevant, since that original use case is still a major use case), though it sounds like the direction we're discussing is pretty compatible with that original vision - Google style can continue to opt in to things consistent with that original vision of "more than whitespace changes when they're worth it" while keeping them off by default for unconfigured clang-format to make it safer-by-default. (LLVM will probably opt into some too, I imagine - like brace addition/removal, etc) Given both Google and LLVM are specific styles anyway, opting them into some of these more-than-whitespace features while having them otherwise off by default seems quite fine to me.<br><br></div><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"><div dir="ltr"><div class="gmail_quote"><div>I think that's more-or-less what MyDeveloperDay has been saying? I think that sounds reasonable to me (we could potentially rename the existing features that do change more than whitespace, like include sorting - to match the naming convention of "this changes the token sequence/can have an effect on how/whether code compiles" - while keeping it on by default for backwards compatibility).</div></div></div></blockquote><div><br></div><div>It is, intentionally so. I didn't mean to hijack the thread, just validate the original point.</div><div><br></div><div>Like the miscommunication you pointed above, this was a reply to a specific point to stick to the original design for the sake of "this is what we wanted back then", which I don't think it's a good policy.</div><div><br></div><div>--renato</div></div></div>
</blockquote></div></div>