I’ve been a regular participant on the Swift Forums since the language was originally open-sourced in 2015. This was back when the forums weren’t even the forums yet—there were only mailing lists.

In those five years, there are only a few posts that have really stuck in my memory, and only one that stands out from the others. It’s an evolution thead from April of 2018 titled Even and Odd Integers. The proposal is a straightforward one: introduce isEven and isOdd convenience properties on BinaryInteger. The prospect was quickly raised that isEven and isOdd are not sufficiently general, and that this API should take the generalized form isDivisible(by:).

The reason this thread claims the ‘favorite’ title for myself begins at post #58. Dave DeLong suggested that isDivisible(by:) could be a misleading name—after all, any integer is technically divisble by another non-zero integer, the quotient just might not be an integer itself. A better name, Dave said, would be isEvenlyDivisible(by:).

What followed this humble bikeshed was dozens of comments debating the spelling and precise semantics of the isDivisible(by:) API. Does “divisible” imply “evenly divisible” when we know we’re dealing with integers? Should x.isDivisible(by: 0) be false, or should it crash at runtime? What about 0.isDivisible(by: 0)? Shouldn’t x.isDivisible(by: y) imply that x / y will always succeed?

This debate continued for nearly fifty posts until user Dany_St-Amant suggested that the API be named isMultiple(of:) rather than isDivisible(by:):

Silly question based on one of the examples in one copy of the proposal.

_sanityCheck(bytes > 0 && bytes.isDivisible(by: 4), “capacity must be multiple of 4 bytes”

Is the name isDivisible(by:) derived from its implementation or its usage? Not sure if I’m alone in this position but when using the implementation of isDivisible(by:), I’m mainly looking for multiples of a specific number.

So would it better to use isMultiple(of:)?

Following along with this thread contemporaneously, Dany’s post felt like a mic-drop moment. A simple name change provided obvious answers to all the questions that had dominated the preceding posts. Of course “multiple” implies even divisibility. Of course x.isMultiple(of: 0) should be false (unless x is 0, in which case it should be true!). Of course x.isMultiple(of: y) doesn’t necessarily imply that x / y will succeed. The discussion immediately converged on isMultiple(of:) as the ‘proper’ spelling for this API.

This thread wasn’t elevated to my favorite simply because of an elegant solution to a long debate, though. It’s claimed that postion because the ultimate solution was so completely accessible, and presented so humbly. Anyone, at any level of experience with Swift, could have come up with isMultiple(of:), and there were many highly intelligent individuals participating in the debate over the semantics of isDivisible(by:). Dany began their post “[s]illy question,” not realizing that they were providing the perfect solution that everyone had been searching for.

(Note: I don’t mean to imply that Dany_St-Amant is an inexperienced Swift user by any means. I don’t know Dany and have no idea what their level of experience is, which is my whole point! The isMultiple(of:) naming could have come from someone at any level of experience, high or low.)

I’m not exaggerating when I say that this thread (and Dany’s post specifically) has been one of the the most important moments for combatting my own feelings of impostor syndrome when participating on the Swift forums. The lessons are multiple, and applicable beyond the forums themselves:

  • Seemingly obvious solutions are often not so obvious in practice.
  • Just because there are smart(er) people in the room, does not mean that they’ve thought of everything.
  • Everyone, even those less experienced than yourself, may have valuable contributions simply by virtue of being a different person with a different thought process.
  • Even the best ideas can (and should!) be communicated humbly.

To those that feel less expereinced or less qualified to participate in technical discussions, let Dany’s post reassure you that you are still able to provide extremely valuable perspective. To those that are more experienced or often feel like the smartest one in the room, let Dany’s post convince you that everybody’s perspective should be solicited and considered—you likely haven’t thought of everything.