[swift-evolution] [Pitch] #warning

[Ben Langmuir]

> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> On May 29, 2016, at 12:58 PM, Erica Sadun <erica at ericasadun.com <mailto: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 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/83c416da/attachment.html>