[swift-evolution] [Pitch] #warning
me at lmpessoa.com
Sun May 29 17:49:22 CDT 2016
Tools like SonarQube can raise a "warning" for comments started with "TODO:" or "FIXME:". Wouldn't it be more interesting if those could be presented as warnings instead of using #warning? And this could be an optional setting as commented would not influence compilation.
From: "Will Stanton via swift-evolution" <swift-evolution at swift.org>
Sent: 29/05/2016 07:09 PM
To: "Harlan Haskins" <harlan at harlanhaskins.com>
Cc: "swift-evolution" <swift-evolution at swift.org>
Subject: Re: [swift-evolution] [Pitch] #warning
+1 to #warning or optionally(?) emitting something like TODO: more visibly!
In past ObjC projects, I have used #warning to confirm the right macros were enabled.
I often (1) work around differences between the iOS simulator and device with TARGET_IPHONE_SIMULATOR (+similar) and (2) change API endpoints among sandbox, production, etc… (which may not relate to whether the open project is debug/release)
For instance, I have code like:
#if TARGET_IPHONE_SIMULATOR || API_DEBUG
#warning DEBUG API: Do not release
I check that release builds do not emit a “warning Do not release” before submitting/deploying.
I think it would be great if (1) lines/branches of Swift source with #warning or something like INDICATE: are highlighted and (2) FIXMEs, TODOs, warnings, etc… are emitted and put into the Issues Navigator of Xcode.
In the past, both of the above (line highlighting and the ease of checking the Issues Navigator for “warning: Do not release” in Xcode) were conducive to my sanity:
Issue highlighting from the last build seems more reliable than syntax highlighting. Xcode syntax highlighting colors (1) sometimes goes down (I’ve encountered SourceKit crashes pretty often) or (2) is wrong (perhaps macros weren’t detected correctly).
Also, while (3) using schemes and (4) seeing the -Doptions in the build command are useful, they are less visible by themselves.
> On May 29, 2016, at 4:20 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> As to #warning, Swift’s use of warnings are significant different than the use in C. In C compilers, many of the warnings produced *should* be errors, but can’t be because that effects language conformance and could break a large body of code. Swift doesn’t have this problem, so it treats warnings as “things that should be addressed before you commit your patch, but shouldn’t block a build if (e.g.) you’re in the middle of a big refactoring”. For example, an unused variables is a warning in Swift.
> This difference in policy is what makes me question where #warning makes sense for Swift. OTOH, errors in Swift are used in exactly the same way as in C compilers, which is why bringing #error forward makes sense to me.
swift-evolution mailing list
swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution