[swift-dev] Categorization of warnings in Swift

[Douglas Gregor]

> On Jan 13, 2016, at 2:28 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
> 
>> 
>> On Jan 13, 2016, at 13:51, Michael Ilseman <milseman at apple.com <mailto:milseman at apple.com>> wrote:
>> 
>> 
>>> On Jan 13, 2016, at 1:43 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>> 
>>> 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?
>>> 
>>> 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 know what code you're actively changing, and only suppress the warning there.
>>> 
>>> (We do have some ad hoc categorization today, including "REPL mode" as you mentioned. I'm fine with making that something more general.)
>>> 
>> 
>> 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.
>> 
>>> I guess I'd rather avoid eagerly classifying warnings, and I'll continue to argue against -W* and -Wno-* flags for the time being.
>>> 
>> 
>> 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?
> 
> 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).

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.

	- Doug


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160114/48292554/attachment.html>