My pick of the best for this year…
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!
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.
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.)
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.
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:
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:
I have some exciting news to share: starting next month, I'm going to be First Officer ????????✈️ on @tim_cook’s private jet. Finally bringing together my ❤️ of ????and ✈️.— Nacho Soto (@NachoSoto) April 1, 2018
At a few minutes past midnight I posted the article How to cut Swift compile times by half, wherein I made a shocking revelation:
Apple had taken the initial step towards becoming the world’s first trillion dollar company: Apple had created a fork of Bitcoin called SwiftCoin.
How could Apple do such a thing? Why would Apple do such a thing. Well, it was all part of their drive to become the world’s first trillion dollar company:
They knew developers were deeply envious of language features such as generics, operator overloading, and first-class functions, so they crafted a plan to introduce a new language to desperate developers – a language that would also secretly mine SwiftCoin while pretending to compile.
Despite my dazzling use of After Effects, it won’t surprise you to learn that SwiftCoin isn’t real – sorry!
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 a speaker at Swift events around the world. If you're curious you can learn more here.
Link copied to your pasteboard.