SE-0367: Conditional compilation for attributes

Hi everyone. The review of SE-0367, Conditional compilation for attributes, begins now and runs through August 15st, 2022.

Reviews are an important part of the Swift evolution process. All review feedback should either be on this forum thread or, if you would like to keep your feedback private, directly to the review manager by DM. When messaging the review manager directly, please keep the proposal link at the top of the message and the evolution identifier in the subject line.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  • What is your evaluation of the proposal?
  • Is the problem being addressed significant enough to warrant a change to Swift?
  • Does this proposal fit well with the feel and direction of Swift?
  • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at: https://github.com/apple/swift-evolution/blob/main/process.md

Thank you for helping review this proposal.

Joe Groff
Review Manager

9 Likes

+1 on the proposal, it seems like a very natural solution to the problem.

I have one minor suggestion regarding the interaction with custom attributes:

While the built-in attribute that enables the feature will be recognized by hasAttribute (e.g., hasAttribute(propertyWrapper) will evaluate true ), the custom attribute will not (e.g., hasAttribute(MyWrapper) will evaluate false ).

Would it make sense to explicitly diagnose attempts to use hasAttribute(MyCustomAttribute) when it is possible to do so? If there is a visible definition for the custom attribute with the name then the compiler could reject the hasAttribute condition to ensure that the developer understands that it will not work for property wrappers etc.

2 Likes

Additionally, I wonder if—sorry, bikeshedding—we should name it hasBuiltinAttribute(…): it would be self-documenting why such a query returns false for a custom attribute.

By contrast, it’s explainable why hasAttribute would return false in that scenario but still awkward because at face value it’s inaccurate—one actually has the queried attribute.

9 Likes

Such a warning would be a bit of a mess to implement, because compiler conditionals like hasAttribute are evaluated early in the parser and are then thrown away. However, you'd need to retain that information somewhere so that a much later semantic phase capable of doing name lookup on MyCustomAttribute could do the check.

Doug

2 Likes

This proposal is most welcome -- conditional compilation for attributes fixes a long-standing papercut for maintainers of Swift libraries, and reduces the need for external code generation tools. hasAttribute() reduces the need to deal with error-prone and opaque version numbers, which will also be very useful.

While we will still need to carefully copy-and-paste the same set of complex conditional attribute incantations over a multitude of declarations, but at least we will no longer need to duplicate the declarations themselves. Huge thumbs up -- thank you very much for doing this work!

1 Like

Thanks all for participating in the review! As @Joe_Groff has announced, the review has concluded and SE-0367 has been accepted.