Swift: Unicode philosophy

Today over at #swift-lang, a lively debate ensued over a hypothetical. What if Swift added arbitrary infix operators including Unicode. Would development be better served with operators like  the intersection operator (“∩”) over the current camelCode approach?

Some advantages are self evident. ∩ is a standard, mathematical representation. It’s widely accepted, widely used, and you’ll encounter it in most math textbooks. Plus it’s generic. It avoids mentioning a specific collection type, which would be required for selectors.

Despite this, I found myself arguing against (or at least against the overuse of) generic Unicode operators. While I welcome Unicode support in Swift, I see it best used to enable native language development. Unicode creates localized variables that make better sense than forced anglicizations. (Admittedly, I don’t see the point of cute dog-cow variables that show off language capabilities rather than enhance day-to-day development.) Even though this  operator is a decided win in the specific merits, I felt Unicode operators failed in the more general case.

I still experience occasional APL flashback nightmares.  The language wasn’t just a horrible experience in tracking down the right characters to create code. Once written, it was  virtually unintelligible even to those who had created those routines. Having experienced write-only code in the classroom, I’m not eager to return there in the app store.

Using Unicode operators incurs costs. As ∩ is not part of the standard first-level keyboard access, there’s a creation cost — both the mental overhead of remembering the operator to use as well as the hunt to find the character to enter.

Second, there’s a cost to readability from a cognitive recall/recognition standpoint. I admit the cost here is small since this particular operator is so well defined mathematically. But recognizing “intersectionWithSet” surely will map better to some people than recalling what the ∩ operator does, even if you end up having to create a suite of specialized selectors. This example really depends on the individual’s training. As operators become more self-defined or esoteric, this cost will rise.

Third, there’s a symbolic representation cost. Outside of standard mathematical representations, there’s an organizational overhead involved in choosing and managing representation elements that camel case text avoids. While the intersection operator is well defined, more general operators won’t be. (One shudders at the possibilities of the “Pile of Poo” operator — except perhaps for release calls.)

Finally, there are sharing costs. Any non-ascii code places a burden on documentation and web sites, especially those that don’t offer copy-paste support. You might be especially proficient with & and similar, but not everyone in your organization will be

It’s not that these costs are unreasonable or that some operators aren’t natural fits, it’s that I’m not sure the benefits outweigh those costs when implemented as a whole. While I can argue the other way (put it into the hands of developers who surely will use this parsimoniously and appropriately), I find myself preferring the more textual solution even if both are available.


  • For one I find it strange that I cannot click on your web site’s main logo to go to the home page…

  • That would be because my web design involved one semi-drunken afternoon about 200 years ago.

  • I agree, if more unicode operators were to become a “thing” you would almost need a standards board or some sort of governing body to insure that they were not abused.

  • I write a ton of mathematical code for 3D graphics and scientific applications, and I find something like A⋅(B×C) to be more familiar and readable than A.dot(B.cross(C)). You can do this in Swift (beta3) right now—the language implementation is more permissive than what Apple’s Swift book states. Fortunately, the compiler only seems to permit non-ASCII operators from the Unicode mathematical operators block, so perversions like a

  • You don’t have to go back to APL for strange character nightmares – anyone remember the weird regex characters in MPW? Flipping between MPW and other environments used to drive me nuts.