[swift-evolution] [Pitch] #warning
harlan at harlanhaskins.com
Mon May 30 00:18:52 CDT 2016
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.
On May 29, 2016, at 1:20 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> On May 29, 2016, at 12:58 PM, Erica Sadun <erica at 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.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution