The names of things

Last night, someone was asking what you call the things created by types. My take on the subject is this: Classes, structures, and enumerations are constructs. You create new instances by calling a constructor, even when building things that aren’t reference types.

I avoid calling reference types “objects”. I stick with instances, following the Swift Programming Language’s lead, e.g. “Use the init?(rawValue:) initializer to make an instance of an enumeration from a raw value.” and “Create an instance of a class by putting parentheses after the class name.”

A big naming challenge derives from what do you call the thing that stores a value. The Swift Programming Language has this to say: “Use let to make a constant and var to make a variable”, which is not at all helpful because you end up saying “Declare a variable or constant”, “use the variable or constant as a parameter to the function”, etc, etc.

While constants and variables are “bound symbols”, “value bindings”, or just “bindings”, those are hard names to use in writing. “Create a value binding of 5” doesn’t communicate the way “create a new variable or constant and set its value to 5” does.

This is why, I prefer to stick with variable to describe both in any indeterminate situation. Constants are really immutable variables, egregious oxymoron and all. And, as Joe Groff points out, constants are still variables according to the mathematical meaning of the term.  It’s not a great solution but nearly everyone gets it.

So unless you’re going for precision, go ahead and declare a variable to store that value. If you don’t or won’t mutate it, the compiler will remind you to mark it as a constant. Long live “let variables“. It may not be technically precise but it does communicate expressively.



  • This is a great and much-needed summary!

    The language’s evolution is pushing everyone to think harder about value vs reference types, which creates a need for a consistent name like “instance”. It’s also pushing us to think about mutability vs immutability, as this has consequences for building reference types with value semantics. This demands a .good consistent name like “variable”.

    So I think using “variable” vs “immutable variable” for a var-defined vs let-defined variable, and “instance” to represent whatever a variable refers to, is a good first step to talking about these other issues of type design more fluently.

    I notice Apple’s own usage has taken a while to settle down. In this Apple blog post on value types vs reference types ( ), they’re using the term “instance” in a way that can only be consistently interpreted as what we are now calling a variable, rather than what Apple itself is calling an “instance” throughout the SPL book.

    One cavil I’d offer: I don’t think it’s quite right to say that all Swift variables are “value bindings”. If “value semantics” means what we think it means (supposing there’s agreement on that…), then a reference type instance with mutable properties is not strictly speaking a “value”, because it can never have value semantics. So If a variable is of such a type, then that variable does not bind its name to a value, so it’s not a value binding.

  • Hey Erica! How do you call types conforming to a protocol? I mean as a noun: are they protocol conformants/conformers/adopters/witnesses?

    • Conforming types

      • Perfect! Thank you

  • You say you avoid the term “object.” Can you explain why? Having read some books on object design/thinking, I don’t understand the reason to avoid the term: the instances you talk about are composable, they have behavior, their types can conform to protocols so you can form abstractions; why not “object” then? (:

  • invent a new term: invariable? 😉 Maybe just a value?