swiftoptimizationtype-inferencetype-safetycompilation-time

What is the difference between Type Safety and Type Inference?


How are they different? I get a bit confused because they seem to be similar concepts.

How does understanding them help with optimizing compilation time?


Solution

  • From Swift's own documentation:

    Type Safety

    Swift is a type-safe language. A type safe language encourages you to be clear about the types of values your code can work with. If part of your code expects a String, you can’t pass it an Int by mistake.

    var welcomeMessage: String
    welcomeMessage = 22 // this would create an error because you  
    //already specified that it's going to be a String
    

    Type Inference

    If you don’t specify the type of value you need, Swift uses type inference to work out the appropriate type. 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.

    var meaningOfLife = 42 // meaningOfLife is inferred to be of type Int
    meaningOfLife = 55 // it Works, because 55 is an Int
    

    Type Safety & Type Inference together

    var meaningOfLife = 42 // 'Type inference' happened here, we didn't specify that this an Int, the compiler itself found out.
    meaningOfLife = 55 // it Works, because 55 is an Int
    meaningOfLife = "SomeString" // Because of 'Type Safety' ability you will get an 
    //error message: 'cannot assign value of type 'String' to type 'Int'' 
    

    Tricky example for protocols with associated types:

    Imagine the following protocol

    protocol Identifiable {
        associatedtype ID
        var id: ID { get set }
    
    }
    

    You would adopt it like this:

    struct Person: Identifiable {
        typealias ID = String
        var id: String
    }
    

    However you can also adopt it like this:

    struct Website: Identifiable {
        var id: URL
    }
    

    You can remove the typealias. The compiler will still infer the type.

    For more see Generics - Associated Types

    Thanks to Swift’s type inference, you don’t actually need to declare a concrete Item of Int as part of the definition of IntStack. Because IntStack conforms to all of the requirements of the Container protocol, Swift can infer the appropriate Item to use, simply by looking at the type of the append(_:) method’s item parameter and the return type of the subscript. Indeed, if you delete the typealias Item = Int line from the code above, everything still works, because it’s clear what type should be used for Item.

    Type-safety and Generics

    Suppose you have the following code:

    struct Helper<T: Numeric> {
        func adder(_ num1: T, _ num2: T) -> T {
            return num1 + num2
        }
        var num: T
    }
    

    T can be anything that's numeric e.g. Int, Double, Int64, etc.

    However as soon as you type let h = Helper(num: 10) the compiler will assume that T is an Int. It won't accept Double, Int64, for its adder func anymore. It will only accept Int.

    This is again because of type-inference and type-safety.

    As you can see in the screenshot the signature is now changed to only accept a parameter of type Int enter image description here

    Pro tip to optimize compiler performance:

    The less type inference your code has to do the faster it compiles. Hence it's recommended to avoid collection literals. And the longer a collection gets, the slower its type inference becomes...

    not bad

    let names = ["John", "Ali", "Jane", " Taika"]
    

    good

    let names : [String] = ["John", "Ali", "Jane", " Taika"]
    

    For more see this answer.

    Also see Why is Swift compile time so slow?

    The solution helped his compilation time go down from 10/15 seconds to a single second.