<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 20, 2016, at 11:23 AM, Michael Ilseman &lt;<a href="mailto:milseman@apple.com" class="">milseman@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 19, 2016, at 10:21 PM, Ted kremenek &lt;<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><br class=""><blockquote type="cite" class="">On Jan 13, 2016, at 4:51 PM, Michael Ilseman via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; wrote:<br class=""><br class="">As far as front-end options, any preferences on the command-line switches? I don’t see a need to keep consistency with GCC/Clang here, so perhaps “-suppress-warnings” and “-warnings-as-errors”?<br class=""></blockquote><br class="">There may not be a need for consistency, but there may be value in being consistent.<br class=""><br class="">If you go with a cohesive model where there are warning categories and separate categories can be enabled, disabled, promoted to errors, etc., then there are merits to GCC/Clang's warning style that I don't think should just be dismissed out of hand. &nbsp;Deviating can provide negative value because it a different scheme that is, well, just different, but conceptually similar to something many developers already know.<br class=""><br class=""></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">That’s a very good point. If we want to offer individual or categorical control in the future, we should design something consistent.</div><div class=""><blockquote type="cite" class=""></blockquote></div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Before dismissing -Werror and -w, consider the taxonomy that they are a part of in the GCC/Clang world:<br class=""><br class=""> &nbsp;-Werror-&lt;warning&gt;<br class=""> &nbsp;-Wno-error-&lt;warning&gt;<br class=""> &nbsp;-Wno-&lt;warning&gt;<br class=""><br class="">This is a very general scheme for controlling warnings. &nbsp;Perhaps "-w" and "-Werror" are a bit special case, so you could always do something like:<br class=""><br class=""> &nbsp;-Wno-all<br class=""> &nbsp;-Werror-all<br class=""><br class="">And just have a warning category for "all warnings".<br class=""><br class="">If you are going to go down the route of having any control for warnings from the command line --- which I realize is a contentious topic on this thread --- I personally believe that the flags should be simple, consistent, and generalized. &nbsp;Having special case flags like "-suppress-warnings" and "-warnings-as-errors" feels more even more special case, and I just have to know what they are.<br class=""><br class="">I'm not married to the -W flags scheme, but it is something that is understood. &nbsp;If we are going to have flags, I'd prefer something that was equally (or more) understandable with a general and simple scheme for controlling warnings.</div></div></blockquote></div><br class=""><div class="">I don’t mind any particulars, just so long as it’s something reasonable and consistent, and provides a user story that is not too confusing. The -Wno-error-&lt;warning&gt; flags does seem confusing, in that it presupposes that a prior flag ended up treating it as an error, while it might actually be off-by-default.</div></div></div></blockquote><div><br class=""></div><div>I agree with you completely. &nbsp;I have nothing against deviating from them for good reason — but those reasons should be well understood and deliberate.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> I would think that there are 5 potential states a diagnostic/category can be in WRT user control: “unspecified”, “default”, “error”, “explicitly on”, “explicitly off”. (Perhaps “unspecified” and “default” can be folded in together, but we might want to expose explicitly setting as default to the user).</div></div></div></blockquote><div><br class=""></div><div>Hmm. &nbsp;I’m trying to understand what “unspecified” would mean in practice. &nbsp;The diagnostic system would need to do something with an “unspecified” warning, which I assume would mean the “default”.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Rather than rely on order on command line, I’d rather have a very consistent order of precedence that fits intuition. See below for my proposed order of precedence.</div></div></div></blockquote><div><br class=""></div><div>Seems like a great goal. &nbsp;The main advantage of the command line is that it allows the ability to easily provide overrides if the default behavior is articulated in terms of a set of command line options you inherited elsewhere from the build system.</div><div><br class=""></div><div>For example, in some cases being able to pass “additional flags” on a per-file basis has been historically a useful way for a specific file to provide overrides to the default project warning settings.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><div class="">The main things I’m trying to avoid in all this is:</div><div class=""><ul class="MailOutline"><li class="">Complicating compiler maintenance without sufficient benefit</li><li class="">Complicating the user story</li><li class="">Painting ourselves into a compatibility corner</li><li class="">Categorization merely as an exercise (taxonomy without use case)</li></ul></div></div></div></div></blockquote><div><br class=""></div><div>These sound great, but also a bit abstract. &nbsp;I’m also not so worried about the latter. &nbsp;The categorization we are talking about here is about the ability to enable/disable any warning and to change the policy on each warning. &nbsp;Whether or not warnings are grouped into logical (and useful) groups really comes down to whether or not you want to turn on/off groups of warnings at a time that are naturally related.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""></div><blockquote type="cite" class=""><div class=""><br class=""></div><div class="">Perhaps I'm the outlier here, but I personally think that "warning flags result in style dialects" is not an anathema. &nbsp;There is some code where stylistic enforcements need to be stricter for a variety of reasons. &nbsp;While I think we should aim for a common set of warnings that are enabled to establish good hygiene in Swift code, I do think there will be cases where more warnings/errors are desired beyond what the core language defines.<br class=""><br class="">I agree we don't need to eagerly classify warnings, but I'd also like to understand your criteria for why -W flags are bad thing in general and what you'd prefer to see as a better direction. &nbsp;I certainly don't see it that way. &nbsp;My fear is that if we are overly conservative about not having precise control over warnings is that we may hold back on adding useful warnings to the compiler because they will not be appropriate for everyone.<br class=""><br class="">I also don't see #if as a solution for warning control, as you indicated in another message, as I see legitimate cases where more aggressive warnings may be desirable to enable in certain contexts. &nbsp;There is also Chris's comments about other contents, like Playgrounds, where some pedantic warnings that may be on by default provide less value.</div></blockquote><div class=""><br class=""></div><div class="">I would propose the following precedence, which matches basic intuition:</div><div class=""><ol class="MailOutline"><li class="">Individual control</li><li class="">Use case control</li><li class="">Categorical control</li><li class="">Global control</li></ol><div class="">E.g. If someone bothered to single out a warning, that should take precedence over others. If there’s a conflict at a precedence level, we error.</div><div class=""><br class=""></div></div><div class="">By “use case” control, for lack of a better name off the top of my head (please suggest one!), I mean situations in which diagnostics are not grouped by kind or any other logical grouping. Rather, they appear together in situations that commonly might want to be controlled. These are often diagnostics which would be cross-cutting of any hierarchical categorization by kind. Some examples:</div><div class=""><ul class="MailOutline"><li class="">Warnings about features that are currently in transition, which many users don’t want to see if they want to be able to compile warning-free on multiple compiler minor versions.&nbsp;</li><li class="">Opting into extra-stringent stylistic warnings that we wouldn’t normally want to thrust upon normal users (but, not style dialects, just a spectrum of stringency).</li><li class="">The kinds of diagnostics that users like Playgrounds just shouldn’t care about, e.g. unused definitions.</li></ul><div class="">The aim being that there’s a specific user or use-case in mind when defining one, as opposed to having them as an organizational grouping. I don’t feel like these would naturally tend to have much, if any, overlap with each other and perhaps we can treat them as non-overlapping. They may, of course, crosscut categories, should we ever decide to implement categories.</div></div></div></div></blockquote><div><br class=""></div><div>I hate to say it, but “use case control” naturally fits with a cross-cutting warning category.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Clang’s categories are sometimes “use case” here, e.g. “c++98-compat”, but often are categorical, e.g. "duplicate-decl-specifier”. I think that for the current state of Swift and Swift for the near future, it makes sense to tackle “use case” soon and categorical later if at all. I feel like the more categorical approach is also more likely to be a source of stylistic dialect splitting and of limited value to the user. Power users can use individual control.</div><div class=""><br class=""></div><div class="">I’d prefer to tackle unique-identifiers before tackling individual control, to help with maintenance and not face a compatibility problem. If this is seems very valuable to Swift, we can also pursue automatic and hyperlinked documentation produced from the diagnostic definitions, etc.</div></div></div></blockquote><br class=""></div><div>One possibility is to make “use case control” and “categorical control” distinctly different in a fundamental way. &nbsp;For example, perhaps all warnings can be divided up into hierarchical groups &nbsp;(groups only overlap if they are a subset) based on categorical control, and those groups can have defaults that are defined in terms of the leaves. &nbsp;The “use case” control has no defaults, but provides a knob to explicitly turn a group of warnings on or off, essentially overriding the other behavior.</div><div><br class=""></div><div>What does “global control” mean in your taxonomy?</div></body></html>