Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via email or direct message on the forums. If you send me email, please put "SE-0224" somewhere in the subject line.
What goes into a review of a proposal?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift.
When reviewing a proposal, here are some questions to consider:
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?
Positive, with one little note regarding this paragraph:
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.
It's true for patch releases. But statements about future (non-patch) releases exist, when you write code that compiles in both Swift N-1, Swift N in Swift N-1 compatibility mode, and genuine Swift N. They are handled with #if compiler(>=N).
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, because until a fellow member of this forum told me I could use the ! operator, I remember writing code like below (nothing between the if and the #else):
#if swift(>=...)
#else
...
#endif
This proposal will reduce the chance for other developers to use a missing operator, curse, and write such an odd workaround.
Does this proposal fit well with the feel and direction of Swift?
Yes. It is natural that compile-time checks support more and more expressions.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Positively: I guess there is a LLVM_VERSION macro somewhere that developers can compare in all possible ways with a C++ compiler.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
The proposal text will be amended to include the mention of the change of behavior to #if compiler, which is also reflected in the implementation and logically fits in with this change:
Thank you to everyone who participated in this review!