Type Inference on Andrew Bancroft

Expanded Thoughts on Swift’s Type Inference

Thu, 21 Aug 2014 02:19:45 +0000

In my recent op-ed on clean coding in Swift focused on Type Inference, I began by saying,

Quick! Tell me! What is the Type of the birdDetails constant in this code example:

let birdDetails = birdDetailsFromStorage()

With no additional context to glean information from, the correct answer to the question is, “I have absolutely no clue…”

But is that concluding assertion true? Hmm…

I’m learning, and as I’ve weighed a recent Twitter conversation and thought on a comment thread that Rob Napier made on the post quoted above, I’m compelled to expand a little on my first post on Type Inference as it relates to clean code in Swift.

Something struck me as I read Rob’s comment: Why wouldn’t I know the Type that would be inferred from what is returned by birdDetailsFromStorage() and assigned to birdDetails? Presumably, I named the function what I named it intentionally. The part I missed, was that if I had designed well and created a Type called BirdDetails (say, a Struct as Rob proposed), then all of a sudden, an inference can be made by both the compiler and a human that the birdDetails constant is… well… an instance of BirdDetails. Imagine that!

To quote Rob (emphasis added):

Type inference should only be used when the result is unambiguous, but the best solution is to make the result unambiguous.

Bingo. The best solution is to make the result unambiguous. You and I as code authors are in charge of the clarity or ambiguity of our code – it’s up to us to make the results of our function evaluations unambiguous.

When I named the function birdDetailsFromStorage(), I heavily implied something about its return Type in the name. I even implied it in the name of the constant. I was expecting the return Type to be something that encapsulated whatever “bird details” are – I just didn’t realize it at the time (although it’s super obvious now)!

The very name of a thing sets expectations for you and the readers of your code. It’s our job to set ourselves up for that expectation to be fulfilled! Be predictable with the return Type of your functions for your own sake. A function signature should be such that when you run across birdDetailsFromStorage()in some piece of code, you are able to legitimately expect it to return a BirdDetails.

Using this predictable, convention-based approach to give humans the right clues about what the compiler is going to compute a Type to be makes Type Inference a totally legitimate language feature to embrace for the sake of your code’s clarity and simplicity.

I’ll leave you with a final quote from Rob’s comments:

Don’t go implying that you’re returning one thing when you’re returning another. If you must, then yes, explicit types are your punishment. 😀

Thank you Rob for your insight and feedback. You can read more of Rob’s work at http://robnapier.net.

Clean Coding in Swift – Type Inference

Wed, 13 Aug 2014 04:22:25 +0000

Quick! Tell me! What is the Type of the birdDetailsconstant in this code example:

1let birdDetails = birdDetailsFromStorage()

With no additional context to glean information from, the correct answer to the question is, “I have absolutely no clue…” Or is it?

“Not fair!”, you say. “In the real world, I’d have the ability to option-click and learn the type from a pop-up tooltip, or learn this information by inspection from Xcode’s utilities panel.”

Truth. We would. But… should we have to for an example like the one above? Could we have helped ourselves out a bit by being explicit about the type of birdDetails?

This was the question I asked myself as I set out to determine how and when I prefer to explicitly specify the Types of my variables and constants at declaration-time, rather than letting the compiler infer the Type for me.

Type Inference is powerful and convenient. It enables us to leave off explicit type specifications when we declare a variable or constant, leaving us with nice, terse, clean-looking code. But in reality, for examples like the one posed above, is clean-looking truly “clean code”?

From Apple’s documentation:

Type inference enables a compiler to deduce the type of a particular expression automatically when it compiles your code, simply by examining the values you provide.

The key phrase that stuck out to me was this: “Type inference enables a compiler to deduce the type of a particular expression…”. Humans are not compilers!

I don’t know about you, but I could use all the help I can get when it comes to figuring out simple things like the Type resulting from an expression. Sure, I could rely on the IDE, but in debugging, or in trying to simply read and understand what the intention of my code is when I come back to it sometime later, I want to focus on the code, not on pop-up tool tips or inspector panels.

For instances where deducing the type is not simple for a human to do (and I mean really simple), I’m getting to where I prefer to specify the Type up-front. We’re used to doing this in Objective-C, and I even do it in C# when using var would obscure things. When a language gives me the option to be clear about Types, I try to take advantage of that valuable language feature for all but the simplest of situations.

The Simplest of Situations

Let’s think for a moment about this so-called “simplest of situations”. I would define such a situation to be when the Type resulting from an expression can easily, at a glance, be inferred by a human being without assistance from an IDE. It’s all about context here, and for these simplest of situations, I love Type Inference.

Compare the following two lines of code:

1let birdDetails = "Swift"

and

1let birdDetails: String = "Swift"

In the example just presented, typing “: String ” to explicitly specify birdDetails‘ type is superfluous in my opinion (and I prefer not to be repetitively redundant when I can). It’s crystal clear that birdDetails in this example is a String.

However, in situations like the one at the beginning of the article where, by simply looking, I would have to answer, “I have no clue what the Type of this is”, my preference / proposal for your consideration would be to go ahead and specify the Type at declaration time. Consider:

1let birdDetails: (genusSpecies: String, commonName: String) = birdDetailsFromStorage()
2
3
4//... somewhere else in a Swift file far, far away ...
5
6
7func birdDetailsFromStorage() -> (genusSpecies: String, commonName: String) {
8    return ("Apus apus", "Swift")
9}

When I’m writing this the first time, I can spend the time looking up the function’s return Type and specify it when I declare my constant. It will make my life so much easier down the road.

Don’t stumble over the fact that birdDetails is a tuple type (String, String). The point is that the function could have returned anything, and it would still have been impossible for me to tell you what the Type of the constant was just by looking, had I not specified it upon its declaration.

Being explicit about the type in the declaration has great potential to immediately help us get our bearings around a particular set of code when we return to it after any length of time. And it seems to me that one of the principal goals of writing clean code is to help ourselves and our teams make sense of code quicker so that everyone’s happier and more productive.

Whew. That was a long-winded exploration of some things to think about when relying on (or avoiding) Type Inference in your own code. Thanks for reading!

Since publishing this op-ed, I’ve expanded my thoughts on Type Inference as it relates to clean coding practices in Swift. I highly recommend that this post be read and considered alongside my latest musings,which were heavily influenced by Rob Napier’s comments below.