SE-0362: Piecemeal adoption of future language improvements

Evolution Proposal Reviews
3

Not attempting a review of the full proposal, but just want to jot down this one (minor) point so that I don't forget:

To prevent this issue for any future extensions to the #if syntax, the compiler should not attempt to interpret any "call" syntax on the right-hand side of a && whose left-hand side disables parsing of the #if body, such as compiler(>=5.7) or swift(>=6.0). For example, if we invent something like #if hasAttribute(Y) in the future, one can use this formulation:

#if compiler(>=5.8) && hasAttribute(Sendable)
...
#endif

On Swift 5.8 or newer compilers (which we assume will support hasAttribute), the full condition will be evaluated. On prior Swift compilers (i.e., ones that support this proposal but not something newer like hasAttribute), the code after the && will be parsed as an expression, but will not be evaluated, so such compilers will not reject this #if condition.

So that we're not unduly restricting future compatibility to one formulation only, it'd be good to have the same allowance for short-circuiting where the condition is expressed as #if compiler(<99) || ....

This may not be the primary way in which users are likely to use feature gating with hasAttribute, but other future extensions of #if may be most naturally expressed in such a way, and it is similar to #if compiler(>=99) && ... in that the right-hand side can be appropriately ignored in prior versions of Swift.

5 Likes