The Beauty of Apple Swift Emojicode…

Swift (and to be fair other languages) supports unicode characters within the language. It sounds a reasonable feature; to allow non Latin-1 characters to be used, such as Kanji. After all, why should a native Japanese developer be forced to name variables, classes, methods et al using a predominantly English character set?

But, unicode supports far more than just language oriented characters, and in the hands of – shall we say – more playful software engineers, there may be trouble ahead… you could possibly expect to see code like this floating around the detritus of the crap-ladden shores of the grand interwebnet…

And remember, this code compiles and runs

Let’s create a class object definition; (apologies for the line spacing, WordPress simply doesn’t care.)

class ?

{

    private var ? = “”

    private var ? = false

    

    init(?: String)

    {

        self.? = ?

    }

    

    func ??() -> Bool

    {

        //  ? likes Charlotte’s Web! Some ?!

        return true

    }

    

    func ?(?: Bool) -> Bool

    {

        // ? likes ?s so if given one, ? eats it

        if(?)

        {

            ? = ?

        }

        return ?

    }

    

    func ?(?: Bool) -> Bool

    {

        // ? does not like ?!

        return false

    }

    

    func ?() -> Bool

    {

        // is ? full?

        return ?

    }

}

“What the?” you may ask. No, dear reader, your eyes do not deceive you. All those cute little emoji’s are correct, and not code characters mistranslated by WordPress.

We can indeed create a ?(pig) class, and ask it if it likes bacon with func ?(?: Bool).

Now let us say we want to breed some ?s… a Pig Factory object would be useful…

class ??

{

    static func ??(?: String) -> ?

    {

        let ?? = ?(?:?)

        return ??

    }

}

And of course, now we can ‘breed’ pigs, we need a farm to manage them, and feed them (provided they like Charlotte’s Web, of course)… one hundred pigs should just about do the trick…

class ?

{

    func ???()

    {

        let ?? = 100

        

        var ?? = 0

        

        while(?? < ??)

        {

            let ?? = ??.??(?: “Bob”) // every ? is called “Bob” as they probably don’t answer by name anyway

            

            if ??.??()

            {

                if !??.?()

                {

                    if(!??.?(?:true))

                    {

                        _ = ??.?(?:true)

                    }

                }

            }

                

            ?? = ?? + 1

        }

    }

}

And finally, for irony’s sake, we’ll use some clear English to get our farm to create some pigs…

        let farm = ?()

        farm.???()

I can tell you, stepping through this in debug to make sure it ran, was a pure joy… while the code runs and does indeed create ??s, Xcode’s debugger simply would not have any of it, and jumped around like a crazed kangaroo on acid. Nice. I wonder what kind of experience our Japanese colleagues have trying to debug their natively named methods…

Glibness aside (and above is very glib!) there is value in supporting unicode ‘in language’, however, Apple, please restrict it to actual ‘text’ language instead of stupid symbols? Naturally, allow anything inside string objects or quotation marks as you may validly want to display them in UI, but for the actual code itself, text only! Also, try actually testing that all the toolchain supports them? Like, say, the debugger? Slightly important, not too easy to miss… really. I can only hope that actual software engineers can resist, and if they can’t that whoever’s reviewing their code uses a damned big stick to smack the emoji’s back into real text.

As an aside, apparently Apple did ban all the unicode line/border characters to stop developers drawing unicode art boxes around everything in their code. So they clearly realised this would be abused by someone.

Several steps too short, yet again Apple… though who cares, really, right?

Leave a Reply

Visit the awesomeness ofDominium!