+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 [Declarations] #warning DEBUG API: Do not release #else [Different declarations] #endif 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. Regards, Will Stanton > On May 29, 2016, at 4:20 PM, Chris Lattner via swift-evolution > <swift-evolution@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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
