> 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.
The example I've mentioned with #error, doesn't necessarily lead to an error,
but can just issue a #warning("Untested OS, proceed carefully.") - it IMHO
doesn't necessarily be fatal.
My issue with this being handled by Xcode (and generally with any feature
discussed here that someone suggests it should be handled by Xcode) is that
Xcode is the least customizable IDE I've ever seen and from what I've talked to
some Xcode developers via bugreport.apple.com, they are not very keen on adding
any customization features. But sadly I haven't found a better IDE.
Yes, I admit, I have abused #warning in the past (ObjC/C) to make sure I don't
forget to implement something before shipping the product (usually during
refactoring, so that I don't forget to come back and finish refactoring
something). And with Swift, I have made TODO comments and of course, I've
forgotten about a few places. It makes you search for TODO or FIXME all the
time. The jump bar is way too hidden and not visible, a developer can't be
expected to open each file and go through the jump bar for each file...
So a solution for this would be for Xcode to provide an option to issue
warnings for TODOs and FIXMEs - and we're back to warnings.
Charlie
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
