NEW! Master Swift design patterns with my latest book! >>

Swift April Fools for 2018

Paul Hudson       @twostraws

Depending on your taste for hoaxes, April 1st is either a day of fun and frolics or a day when you turn off social media and avoid people.

Here in the iOS community we had our fair share of good jokes, and I thought I’d pick out my favorites in case you missed out. Well, at least I think they are jokes – you decide!

Here comes LOLCode

Robert Widmann and Harlan Haskins crafted a Swift Evolution proposal to implement a new #lolcode literal in Swift that allowed for inline compilation of LOLCode. For example:

#lolcode(
  I HAZ A z
  I HAZ A x
  x R 6
  z R SUM of x and 76
  VISIBLE z BTW prints ’82’
)

If you haven’t heard of LOLCode before, the pair have you covered:

LOLCode is a modern, imperative, dynamic programming language widely regarded as the natural successor to SmallTalk. Its consistent syntax and cheerful outlook on programming inspire confidence in even beginner users, and its support for interoperability with C make it a natural target for low level systems programming for advanced users.

This alone was a fantastic entry in the annals of Swift fools, but Robert and Harlan had to go further: they actually implemented their proposal:

“This will make Swiftc the world's first optimizing compiler for LOLCode, and the world's first complete LOLCode-to-LLVM compiler.”

Surely with such a one-two combo I could end this article right here? Nope – they snuck the best in at the very end…

After publication, the authors have, in fact, identified a previous Swift proposal under which LOLCode constructs have made it into the language. We are deeply annoyed that the proposal in question has chosen the name "Access Control" to mask this fact.

Probably safe is better than nothing – right?

Jordan Rose of Swift compiler fame has posted a draft Swift Evolution proposal to the Swift Forums describing a new ProbablySafeBufferPointer, along with a complete implementation that could be merged as soon as Swift 4.2. Probably.

We’re all familiar with the problems of UnsafeBufferPointer, so Jordan’s new ProbablySafeBufferPointer is designed to check to make sure that accesses to the buffer are safe – or at least probably safe.

From the proposal:

This provides a non-owning buffer pointer that’s nonetheless probably safe to access (as in, the program will abort rather than corrupting arbitrary memory in the process if it can figure out that something went wrong). Sure, it’s not 100% safe—static data and stack data can’t be bounds-checked, and heap data might get deallocated and something else reallocated in its place—but it’s better than nothing, right? (No.)

The Dog Cow lives on!

Erica Sadun – easily the most prolific community member of the Swift Evolution process – wrote up a new Dog Cow literal proposal for Swift Evolution. Dogcows have a long and proud history on Apple platforms, and Erica suggests a remarkable use for them in Swift.

From her proposal:

When not bound as a symbol, this proposal allows the "dogcow" literal to be used in place of otherwise unspecified values. Swift infers a value to substitute, automatically introducing the most appropriate value at any use point.

All that’s needed is to make sure the dog cow has the right set of default values, and this proposal is ready to ship ASAP. Erica helpfully provides some for starters:

In strings, it is "moof", as a number 42, as a Bezier path, it describes the rounded rect, as a set, all Stooges -- including Swift.Shemp, and as a tree structure must express several missing branches, its curvature be matched to the golden mean, and the initials of a pair of lovers be carved into its data.

Emoji is the one true language

Unlike Objective-C, Swift allows us to use emoji as part of the names for all our code, so John Sundell announced a new coding paradigm to patch: emoji-driven development.

Why emoji? Simple: “Emoji transcends language barriers, reduces verbosity in things like text messages, and can help set the mood in a tweet or email.” And thanks to typealiases, John shows you how you can switch to emoji-driven development today with “no downsides.”

To help you remember how best to use emoji-driven development, John gave this helpful list of rules:

  • Always use emoji when possible
  • Prioritize clarity by removing text
  • Rockets are symbols too
  • Interesting code is best code
  • Long lines of text are hard to read
  • Foster an emoji-driven culture in your team
  • Occasionally use text, but only when needed
  • Organize your code by emoji type (rockets first!)
  • Listen to your inner emoji
  • Spread the word!

Flying high with Tim

While his brother Javi remains blocked by Tim Cook (not an April Fool, he really is!), Nacho Soto found a way to put together his old life as an app developer with his new life as a pilot. Don’t believe me? He posted it on Twitter, so it must be true:

MASTER SWIFT NOW
Buy Practical iOS 12 Buy Pro Swift Buy Swift Design Patterns Buy Practical iOS 11 Buy Swift Coding Challenges Buy Server-Side Swift (Vapor Edition) Buy Server-Side Swift (Kitura Edition) Buy Hacking with macOS Buy Advanced iOS Volume One Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with Swift Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

About the author

Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and Mario Kart world champion. OK, so that last part isn't true. If you're curious you can learn more here.

Was this page useful? Let me know!

Click here to visit the Hacking with Swift store >>