<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 13, 2016, at 4:51 PM, Michael Ilseman via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> 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="">Upon further discussion with Jordan and others offline, I’m not sure it makes sense at this point in Swift to go about doing categorization. Before wrapping up in this area, I’m going to pursue:</div><div class=""><br class=""></div><div class=""><ol class="MailOutline"><li class="">Clean up some existing code, where we have unused categories assigned to all diagnostics (and those categories are arguably useless)</li><li class="">Expose frontend options to treat all warnings as errors as well as options to ignore all warnings</li></ol></div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>I opened PR <a href="https://github.com/apple/swift/pull/980" class="">https://github.com/apple/swift/pull/980</a> to perform this.</div><div><br class=""></div><div><br class=""></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="">Interesting future work could be along the lines of addressing <a href="https://bugs.swift.org/browse/SR-529" class="">https://bugs.swift.org/browse/SR-529</a>. After there’s unique identifiers, then we can re-explore finer grained control.</div><div class=""><br class=""></div><div 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”?</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 2:28 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jan 13, 2016, at 13:51, Michael Ilseman <<a href="mailto:milseman@apple.com" class="">milseman@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 1:43 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Hi, Michael. As one of the people who's been a strong believer of "warning flags result in style dialects", I think it's important to establish a use case here. What will people actually do with warning categories? What warnings will we allow turning off? Under what contexts?</div><div class=""><br class=""></div><div class="">For the "variable never mutated" warning, you mentioned that this doesn't make sense in a rapid experimentation environment. I'd say more specifically that it doesn't make sense in code you're actively changing. But Live Issues should be able to<span class="Apple-converted-space"> </span><i class="">know</i> what code you're actively changing, and only suppress the warning<span class="Apple-converted-space"> </span><i class="">there.</i></div><div class=""><br class=""></div><div class="">(We do have some ad hoc categorization today, including "REPL mode" as you mentioned. I'm fine with making that something more general.)</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I’ll look more at REPL mode and see how to better generalize that. It’s more in line with what I’m trying to accomplish, and it may not make sense to categorize all the warnings in Swift so much as call out limited sub-sets. If that’s the case, and doing so is more so the exception than the rule, then I’m more amenable to tags and/or Kate’s suggestions.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">I guess I'd rather avoid eagerly classifying warnings, and I'll continue to argue against -W* and -Wno-* flags for the time being.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">What about global flags, such as “-Werr” or equivalent? Do you have any thoughts about Dmitri’s point on multi-platform libraries and how they sometimes can trigger strict stylistic warnings excessively?</div></div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I'd rather come up with good answers to #if and/or easy, idiomatic ways to silence most warnings (like assigning to _) over flags and diagnostic regions (Clang's pragmas).</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Jordan</div></div></blockquote></div><br class="">
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=L1bx6ziz999m3vEK6xzEZ8-2BxMso9qH8zmQT-2BB7ieT-2Fw8yjTisIwf273-2BImGbQjIqQkbUQuTnzGxEbZholPmmMzWZ-2Fc7InoZT822iwaDb5ahF0CFsf7JASdSakIiQQGKbe2GsRtdnqqhy27c5ECDzNY0IKBfYAHqRkVoIbNEGi8Ivo8Flw09-2B98iNGKOLIER1PSPkvsXhWlrrg7nFwW8lcPP3KmOmwZHRJ-2Fr2jWlBsqw-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""><div class=""></div><blockquote type="cite" class=""><div class=""><br class=""></div><div class=""><div class="">On Jan 14, 2016, at 8:32 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jan 13, 2016, at 2:28 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Jan 13, 2016, at 13:51, Michael Ilseman <<a href="mailto:milseman@apple.com" class="">milseman@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 1:43 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Hi, Michael. As one of the people who's been a strong believer of "warning flags result in style dialects", I think it's important to establish a use case here. What will people actually do with warning categories? What warnings will we allow turning off? Under what contexts?</div><div class=""><br class=""></div><div class="">For the "variable never mutated" warning, you mentioned that this doesn't make sense in a rapid experimentation environment. I'd say more specifically that it doesn't make sense in code you're actively changing. But Live Issues should be able to <i class="">know</i> what code you're actively changing, and only suppress the warning <i class="">there.</i></div><div class=""><br class=""></div><div class="">(We do have some ad hoc categorization today, including "REPL mode" as you mentioned. I'm fine with making that something more general.)</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I’ll look more at REPL mode and see how to better generalize that. It’s more in line with what I’m trying to accomplish, and it may not make sense to categorize all the warnings in Swift so much as call out limited sub-sets. If that’s the case, and doing so is more so the exception than the rule, then I’m more amenable to tags and/or Kate’s suggestions.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">I guess I'd rather avoid eagerly classifying warnings, and I'll continue to argue against -W* and -Wno-* flags for the time being.</div><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">What about global flags, such as “-Werr” or equivalent? Do you have any thoughts about Dmitri’s point on multi-platform libraries and how they sometimes can trigger strict stylistic warnings excessively?</div></div></div></div></blockquote><br class=""></div><div class="">I'd rather come up with good answers to #if and/or easy, idiomatic ways to silence most warnings (like assigning to _) over flags and diagnostic regions (Clang's pragmas).</div></div></blockquote><br class=""></div><div class="">Our crop of migration-to-Swift-3 warnings is a perfect example of a case where these approaches don’t work well. For example, it is completely reasonable to want to suppress the just-committed ‘typealias’ to ‘associatedtype' warning if you want to keep your code base compiling with Swift 2.[01]. There’s no sensible idiom there, and having to use diagnostic regions would be annoying at best.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>- Doug</div></div></div></blockquote><div class=""><br class=""></div><div class="">Doug, do you think it’s worth pursuing a strategy to handle the migration warnings right now?</div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>