|
| 1 | +# Support 'less than' operator in compilation conditions |
| 2 | + |
| 3 | +* Proposal: [SE-NNNN](NNNN-ifswift-lessthan-operator.md) |
| 4 | +* Authors: [Daniel Martín](https://github.com/danielmartin) |
| 5 | +* Review Manager: TBD |
| 6 | +* Status: TBD |
| 7 | +* Bugs: [SR-6852](https://bugs.swift.org/browse/SR-6852) |
| 8 | +* Implementations: https://github.com/apple/swift/pull/14503 (Stale?) |
| 9 | + https://github.com/apple/swift/pull/17960 |
| 10 | + |
| 11 | +## Introduction |
| 12 | + |
| 13 | +This proposal augments the functionality implemented for proposal |
| 14 | +[SE-0020](https://github.com/apple/swift-evolution/blob/master/proposals/0020-if-swift-version.md) |
| 15 | +with the introduction of a new valid operator in compilation |
| 16 | +condition: "<". The aim is that the syntax `#if swift(<4.2)` is |
| 17 | +supported by the language. |
| 18 | + |
| 19 | +Swift-evolution thread: [Discussion thread topic for that proposal](https://forums.swift.org/t/support-for-more-operators-in-if-swift-build-configuration-option/14343) |
| 20 | + |
| 21 | +## Motivation |
| 22 | + |
| 23 | +The main motivation for introducing a new "<" operator in compilation |
| 24 | +conditions is to be able to write Swift code that is easier to read. |
| 25 | + |
| 26 | +For example, if we want to only compile some piece of code if the |
| 27 | +Swift version is less than 4.2, right now we have to write the following |
| 28 | +code: |
| 29 | + |
| 30 | +```swift |
| 31 | +#if !swift(>=4.2) |
| 32 | +// This will only be executed if the Swift version is less than 4.2. |
| 33 | +#endif |
| 34 | +``` |
| 35 | + |
| 36 | +With the introduction of support for the "<" unary operator, the |
| 37 | +refactored code would be more clear and readable: |
| 38 | + |
| 39 | +```swift |
| 40 | +#if swift(<4.2) |
| 41 | +// This will only be executed if the Swift version is less than 4.2. |
| 42 | +#endif |
| 43 | +``` |
| 44 | + |
| 45 | +In the former snippet, the `!` can be easily missed in a code |
| 46 | +review. The latter snippet reads more like plain English. |
| 47 | + |
| 48 | +Support for other operators like "<=" and ">" is not desired, as they |
| 49 | +make a statement about future releases and they don't account for |
| 50 | +patch releases. That means that client code will need to be updated if |
| 51 | +a patch release didn't fix a particular issue with the compiler, for |
| 52 | +example. |
| 53 | + |
| 54 | +## Proposed solution |
| 55 | + |
| 56 | +The solution is small change in the parser so that the operator "<" is |
| 57 | +supported. Diagnostic messages about invalid unary operators must be |
| 58 | +updated as well. |
| 59 | + |
| 60 | +## Detailed design |
| 61 | + |
| 62 | +The place in the parser where `#if swift(...)` is parsed is |
| 63 | +`ParseIfConfig.cpp`. There are two classes that will require |
| 64 | +modification: `ValidateIfConfigCondition`, to take into account the |
| 65 | +"<" operator, and `EvaluateIfConfigCondition`, to actually evaluate |
| 66 | +the new operator semantics. A new '<' operator for `Version` will also |
| 67 | +need to be implemented. |
| 68 | + |
| 69 | +The diagnostic message when the operator is not valid also needs to |
| 70 | +change. I propose changing it from |
| 71 | + |
| 72 | +``` |
| 73 | +unexpected platform condition argument: expected a unary comparison, such as '>=2.2' |
| 74 | +``` |
| 75 | + |
| 76 | +to |
| 77 | + |
| 78 | +``` |
| 79 | +unexpected platform condition argument: expected a unary comparison '>=' or '<'; for example, '>=2.2' or '<2.2' |
| 80 | +``` |
| 81 | + |
| 82 | +## Source compatibility |
| 83 | + |
| 84 | +This has no effect in source compatibility. |
| 85 | + |
| 86 | +## Effect on ABI stability |
| 87 | + |
| 88 | +This has no effect in ABI stability. |
| 89 | + |
| 90 | +## Effect on API resilience |
| 91 | + |
| 92 | +This has no effect in API resilience. |
0 commit comments