> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> On May 29, 2016, at 12:58 PM, Erica Sadun <er...@ericasadun.com >>> <mailto:er...@ericasadun.com>> wrote: >>> One could make a weak argument that #warning/#error/#message make a nice >>> family of flexible alerts >>> just because they're kind of what we're used to already. >> >> Right: it isn’t a bad thing at all, but it is certainly the case that people >> often request adding features to Swift that they see in other languages. >> Our task is to look at whether the problem is real and significant enough to >> solve, and if the proposal solves it in the best possible way consistent >> with the rest of Swift. >> >> An similar example is "#pragma mark”. Instead of introducing language >> support for it, we codified a comment marker (since it is semantically >> identical to a comment). Xcode picks it up and does the right thing, and I >> think it has worked out well. >> >> 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 sounds exactly like what I’d use #warning for. “I’m in the middle of a > big refactoring, and I haven’t gotten to this part yet; let me put a warning > in so I can test the other part but won’t forget to come back to it.” It > might also make sense for doing a series of commits on a branch when you need > to fix something before merging back to trunk.
+1 to the proposal, and Jordan has captured my feelings very well here so I won’t repeat him. > > I think it is important for such diagnostics to show up in compilation, not > just in IDEs, especially with people using the Swift Package Manager. We > could have the compiler parse every comment looking for TODOs and FIXMEs by > default, and emit those as warnings, but I’d want to find out if that creates > a noticeable difference in parsing time. (It also seems odd that comments > would be controlled by #if, but maybe that’s silly.) > > +1 to the proposal from me, though I agree with Brent that the parentheses > don’t feel right. This is closer to #if and #setline than #available and > #selector. > > Jordan > > P.S. #error is also interesting, but more for “things that should never > happen” (like the else branch of a platform check), which makes it a bit less > important. #info/#message can be useful but I’d like to see a concrete case > before designing it. > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
