Oppose. not to be a negative nancy but i think Ben Cohen’s “too much sugar not enough protein” quote applies to this proposal. A lot of the justifications given in the proposal don’t seem to hold water, examples:
Readability: This proposal significantly improves readability, as expressions read like straightforward English sentences. There is no need to mentally parse and understand non-obvious operator precedence rules (
%has higher precedence than==).
since when was %’s and ==’s relative precedence non-obvious? no one seems to think
if value / 2 == 0
has confusing precedence after all. >> and & are examples of operators with confusing precedence. the ternary ? : is an operator with confusing precedence. an arithmetic operator vs a comparison operator is not confusing precedence…
The
isEvenandisOddproperties are also fewer characters wide than the remainder approach (maximum 7 characters for.isEvenvs 9 for% 2 == 0) which saves horizontal space while being clearer in intent.
2 character difference,,, really just leave out the spaces before the colon in the type annotation and you’ll save just as much…
This functionality will also eliminate the need to use the remainder operator or bitwise AND when querying the divisibility of an integer.
we love circular reasoning
Correctness: It isn't uncommon to see tests for oddness written as
value % 2 == 1in Swift, but this is incorrect for negative odd values. The semantics of the%operator vary between programming languages, such as Ruby and Python, which can be surprising.
The
%operator will also trap when the righthand side is zero. The proposed solution does not.
99% of the time we test for divisibility, the number on the right hand side is a literal constant. it’s unlikely someone will intentionally write value % 0, after all you wouldn’t write value / 0. testing against negative numbers is rare and usually arises in special domain-specific cases and you’re probably already going to be handling those separately anyways.
Discoverability: IDEs will be able to suggest
isEven,isOdd, andisMultipleas 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 toisEvenandisOdd.
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.
in general, discoverability and teachability are rationales we come up with when we can’t think of anything else to justify a feature
no. sorry :(
no
it’s one of those sugar things that can be nice to have but i think just doesn’t clear the bar for inclusion. i’m open (but not crazy in favor) of isMultiple(of:) by itself. i don’t think isEven or isOdd carry their weight in the standard library at all.
i followed the pitch thread and read the proposal through.
i want to make clear this review isn’t in any way a criticism of the proposal authors, I just don’t think the reasons given justify adding these parity properties to the standard library forever.