SE-0196 — Compiler Diagnostic Directives

[jarod (Jarod Long)]

What is your evaluation of the proposal?

+1, I’ve always wanted a #warning directive in Swift.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes. There are workarounds, but imo they’re cumbersome enough to make this feature important.

The workaround I’ve used is to define a global TODO symbol that’s flagged as deprecated, so you can reference that symbol to produce a warning. However, this can only be used on lines where a standalone expression is supported, i.e. inside a function body, which is quite limiting. Also, the deprecation warning is semantically incorrect as mentioned above, and you can’t specify a message at the call site. #warning doesn’t have any of these limitations.

The other workaround I know of is to use a build script to surface TODO comments as warnings, but it’s cumbersome to set this up in every project, and it feels like a hack. Having something standardized and built-in would be very helpful.

Does this proposal fit well with the feel and direction of Swift?

I think it does.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

It’s basically the same as #warning / #error in ObjC, which worked well imo.

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the full proposal and skimmed the discussion.

[Michael_Ilseman]

Did you consider a #assert, which would be an equivalent of C++'s static_assert? That could also tip the balance towards explicit parenthesis.

[harlanhaskins]

That could be cool for mutually exclusive build configurations, but if we added #assert, I’d want constexpr 😈

[David_Moore]

What is your evaluation of the proposal?

Adding these directives to the Swift compiler will be an excellent addition that has a number of particularly handy use cases. Definitely +1 on this.

Is the problem being addressed significant enough to warrant a change to Swift?

Although this might not be a necessarily essential feature, it’s definitely a helpful one that’ll hopefully improve code readability and review.

Does this proposal fit well with the feel and direction of Swift?

Since this is a compiler directive there isn’t necessarily a Swifty feel to it, but that is to be expected with such a feature. However, that being said, it does fit in well with the feel and direction of existing Swift compiler directives.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This is very similar to #pragma when using Clang (i.e., Objective-C, C++, etc…), so it should be intuitive for developers coming from those languages. It also improves on that syntax by using appropriate language that explicitly describes the purpose of the directive.

How much effort did you put into your review?

I read the entire proposal, in addition to the evolution discussion, and was very excited as this is something that I’ve felt Swift was missing.

[Nathan_Gray]

+1

This is a small but significant improvement that will be useful in a variety of contexts. The proposed syntax seems fine to me.

[pkirvan (Paul Kirvan)]

Technically, you can already do that, since “#error” does indeed produce a compiler error. :-)

Oh we know. In Swift as it currently exists you can make an error just by typing ljkhhkljahlkh on the line you want the error to be. Sometimes out of desperation I do just that. However, that doesn’t cover the usage case of wanting a warning, not an error, so that I can compile and test other things in the mean time. This proposal also offers a much more professional looking way to get the error. 😀

[tkremenek (Ted Kremenek)]

Review accepted with slight revision

On February 1, 2018 the Core Team decided to accept this proposal with slight revision over the original proposal.

The only revision over the original proposal is to change the syntax to use #warning(<Message>) instead of #warning <Messsage>. This fits well with most of Swift’s existing compiler directives, and was strongly supported in the review discussion.

The review discussion also covered a variety of possible extensions or variants to this proposal, including support for using #warning as an expression instead of a line directive and support for runtime issues. The Core Team decided that while these directions are interesting and worth exploring, they are complementary to the core functionality serviced by this proposal. Further, keeping #warning as a line directive allows it to be used in a wide variety of contexts, and serves a different need than using it as a placeholder expression.