FWIW, I'm also in favor of adding #error to the language. It would be good to express invariants that the compiler can't know about, like mutually exclusive build config options that affect code downstream.
I'm definitely seeing how #warning might conflict with the goals of Swift's warnings. If there's interest, I would be willing to transform this into a #error proposal. - Harlan On May 29, 2016, at 1:20 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote: >> On May 29, 2016, at 12:58 PM, Erica Sadun <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 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. > > -Chris > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
