- Proposal: SE-0224
- Authors: Daniel Martín
- Review Manager: Ted Kremenek
- Status: Implemented (Swift 5.0)
- Decision Notes: Rationale
- Bugs: SR-6852
- Implementations: apple/swift#14503 (Stale?), apple/swift#17690
This proposal augments the functionality implemented for proposal
SE-0020
with the introduction of a new valid operator in compilation
condition: "<". The aim is that the syntax #if swift(<4.2)
is
supported by the language.
Swift-evolution thread: Discussion thread topic for that proposal
The main motivation for introducing a new "<" operator in compilation conditions is to be able to write Swift code that is easier to read.
For example, if we want to only compile some piece of code if the Swift version is less than 4.2, right now we have to write the following code:
#if !swift(>=4.2)
// This will only be executed if the Swift version is less than 4.2.
#endif
#if !compiler(>=4.2)
// This will only be executed if the Swift compiler version is less than 4.2.
#endif
With the introduction of support for the "<" unary operator, the refactored code would be more clear and readable:
#if swift(<4.2)
// This will only be executed if the Swift version is less than 4.2.
#endif
#if compiler(<4.2)
// This will only be executed if the Swift compiler version is less than 4.2.
#endif
In the former snippet, the !
can be easily missed in a code
review. The latter snippet reads more like plain English.
Support for other operators like "<=" and ">" is not desired, as they make a statement about future releases and they don't account for patch releases. That means that client code will need to be updated if a patch release didn't fix a particular issue with the compiler, for example.
The solution is small change in the parser so that the operator "<" is
supported for both the #if swift
and #if compiler
conditions. Diagnostic
messages about invalid unary operators must be updated as well.
The place in the parser where #if swift(...)
is parsed is
ParseIfConfig.cpp
. There are two classes that will require
modification: ValidateIfConfigCondition
, to take into account the
"<" operator, and EvaluateIfConfigCondition
, to actually evaluate
the new operator semantics. A new '<' operator for Version
will also
need to be implemented.
The diagnostic message when the operator is not valid also needs to change. I propose changing it from
unexpected platform condition argument: expected a unary comparison, such as '>=2.2'
to
unexpected platform condition argument: expected a unary comparison '>=' or '<'; for example, '>=2.2' or '<2.2'
This has no effect in source compatibility.
This has no effect in ABI stability.
This has no effect in API resilience.