> 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
