I am, in the end, rather neutral to the specific proposed additions but leaning slightly against their inclusion, for the same reason as @taylorswift cites: "too much sugar, not enough protein."
However, I believe the justifications advanced in the text are very much inconsistent with the direction of Swift. If this proposal were to be accepted, then those justifications will be cited as precedent for other proposals. Therefore, whatever the fate of the proposed additions themselves, I believe the proposal text itself should be revised or rejected.
Specifically:
There is no need to mentally parse and understand non-obvious operator precedence rules ( % has higher precedence than == ).
While there are non-obvious operator precedence rules, the precedence of == in relation to basic arithmetic operators is not one of them. It is not the purpose of Swift's methods to allow the user to avoid even the most basic use of common operators. This claim should form no part of any justification for adding new APIs.
The isEven and isOdd properties are also fewer characters wide than the remainder approach (maximum 7 characters for .isEven vs 9 for % 2 == 0 ) which saves horizontal space while being clearer in intent.
While Swift does, in general, favor concise APIs, in no case is an API that's spelled using 7 characters more readable than one spelled using 9 characters because there are two fewer characters (and whitespace at that!). This is a non-goal of Swift API design, and no proposal now or in the future should cite such a point as justification for a new API (or even renaming an existing one).
Discoverability: IDEs will be able to suggest isEven , isOdd , and isMultiple as part of autocomplete on integer types which will aid discoverability. It will also be familiar to users coming from languages that also support functionality similar to isEven and isOdd .
The text above is the entirety of the section on why the proposed APIs "aid discoverability." It is axiomatically true that any new member will be found in the autocomplete list; if this argument were sufficient to fulfill the criterion of discoverability, then any addition of a method would fulfill that criterion.
That should not stand: At a minimum, adding methods to a type also decreases the discoverability of all other methods of that type by virtue of the fact that the list of methods grows longer. Integer types already have a very complicated API. This is a trade-off that is not at all represented in this discussion. Moreover, removing one of the most common uses for % decreases the user's opportunities to encounter (and eventually master) a common operator, decreasing the discoverability of that operator.
Trivially composable: It would be relatively easy to reproduce the proposed functionality in user code but there would be benefits to having a standard implementation.
Again, this text is eviscerating the meaning of the criterion. These methods are, for the most part, trivially composable. (Which is fine--a proposed addition could still pass the bar for inclusion based on fulfilling multiple other criteria.) However, if this text were accepted as justification for adding APIs, then almost any trivially composable implementation would pass the bar, as it is axiomatically true that "there would be benefits to having a standard implementation"--that benefit being, namely, that the method is so trivially composable that "it's not worth...defining it manually" if there weren't a standard implementation, as the authors write in the text.
Testing the parity of integers is also relatively common in sample code and educational usage. In this context, itâs usually not appropriate for an author to introduce this functionality (unless they are teaching extensions!) in order to avoid distracting from the main task at hand (e.g. filter, map, etc). It may also be the same situation for authoring test code: it'd be used if it existed but it's not worth the overhead of defining it manually.
See above. The authors write that, in many situations, the function is so trivially composable that it'd not even be worth having if the standard library didn't vend it (so that even an import statement isn't necessary, lest that be too much overhead also).
Is the problem addressed significant enough to warrant a proposal? I do worry that the question of testing for oddness correctly is sufficient to merit an API addition, and for that reason I wouldn't reject the proposed APIs out of hand. That said, during the discussion phase, it was pointed out that there were no examples where the "incorrect" way of testing for oddness in the wild ever caused incorrect behavior, as users only ever wrote that when the numbers they were testing could only ever be positive.
As the authors write, the proposal doesn't fit with the direction of Swift in that it adds a pair of methods that are easy and obvious negations of each other. It's isOdd that has any chance of promoting increased correctness, and it would be (ahem) odd to have only isOdd. (For some reason, intuitively, it seems much less strange to have only isEven.)
I have used other languages with this feature, especially Python; however, I have never felt the need to reach for these APIs instead of the much more common idiom of using % even in those languages.
I have followed the previous discussions and studied this topic in-depth.
