<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 1:43 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=""><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="">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></div></blockquote><br class=""></div><div>Jordan, there is a class of warnings that we want to disable in Playgrounds, simply because they don’t make sense for that use case. </div><div><br class=""></div><div>You could argue that the IDE should just ignore certain errors in this case, but that leads to tight coupling and fragility, this is better managed by having there be a -Wno-playgrounds sort of flag, so we can manage it on the compiler side.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>