Memory Safety in Swift 

Swift monitors risky behaviour that may occur in the code. For example, Swift ensures that variables are introduced before they’re utilized, likewise, memory isn’t accessed once its deallocated, and array indices are checked for out-of-bounds errors.

Swift additionally guarantees that multiple access to a similar region of memory doesn’t conflict, by requiring code that alters a location in memory to have restrictive access to that memory. Since Swift manages memory naturally, more often than not you don’t need to consider getting to memory by any means. However, it’s essential to understand where potential clashes can happen, so you can avoid composing code that has clashing access to memory. If your code contains clashes, you’ll get a compile-time or runtime error. 

Understanding Conflicting Access to Memory  

Memory access occurs in your code when you do things like set the value of a variable or pass an argument to a function. For instance, the following code contains both read access and write access:  

var one = 1

// A read access from the memory where one is stored.

print("We're number \(one)!")

Clashing access to memory can happen when various parts of your code are attempting to get to a similar area in memory simultaneously. Various accesses to a location in memory simultaneously can deliver unusual or conflicting conduct. In Swift, there are approaches to alter a value that spans several lines of code, making it possible to access a value in the middle of its modification.

You can see a comparable issue by thinking about how you update spending that is composed of a piece of paper. Updating the spending plan is a two-step measure: First, you add the things’ names and costs, and afterwards, you change the aggregate sum to reflect the items currently on the list. Before and after the update, you can read any information from the budget and get a correct answer, as shown in the figure below.

While you’re adding items to the spending plan, it’s in a temporary, invalid state because the aggregate sum hasn’t been refreshed to reflect the recently added items. Perusing the aggregate sum during the way toward adding a thing gives you mistaken data.  

This example additionally shows a challenge you may experience when fixing clashing access to memory: There are at times numerous approaches to fix the contention that produce various answers, and it’s not generally evident which answer is right. In this example, depending upon whether you need the first aggregate sum or the refreshed aggregate sum, either $5 or $320 could be the right answer. Before you can fix the clashing access, you need to figure out what it was planned to do.  

Characteristics of Memory Access 

There are three characteristics of memory access to consider with regards to clashing access: regardless of whether the access is a read or a write, the duration of the access, and the location in memory being accessed. In particular, a contention happens on the off chance that you have two accesses that meet the following conditions: 

1. At least one is written access.
2.  They access the same location in memory.
3.  Their durations overlap.

The distinction between a read and write access is normally self-evident: write access changes the area in memory, yet read access doesn’t. The area in memory refers to what exactly is being accessed —for instance, a variable, consistent, or property. The span of memory access is either immediate or long haul.  

Access is immediate if it’s not possible for another code to run that entrance begins however before it closes. By their tendency, two momentary gets can’t occur simultaneously. Most memory access is quick. For instance, all the read and write the instance in the code listing below are instantaneous:

func oneMore(than number: Int) -> Int {

    return number + 1

} 

var myNumber = 1

myNumber = oneMore(than: myNumber)

print(myNumber)

// Prints "2”

However, there are a few different ways to get to memory, called long term access, that length the execution of other code. The difference between prompt access and long-term access is that it’s workable for other code to pursue drawn-out access begins however before it closes, which is called the cover. Drawn-out access can cover with other long-term access and quickly get to.  

Overlapping accesses appear primarily in code that uses in-out parameters in functions and methods or mutating methods of a structure. The specific kinds of Swift code that use long-term accesses are discussed in the sections below. 

Clashing Access to In-Out Parameters  

A function has long term write access to the entirety of its in-out parameters. The write access for an in-out parameter begins after the entirety of the non-in-out parameters have been assessed and goes on for the whole length of that function call. On the off chance that there are numerous in-out boundaries, the compose gets to begin as per the pattern in which the boundaries show up.  

One outcome of this long term writ write access is that you can’t get to the first variable that was passed as in-out, regardless of whether checking rules and access control would somehow allow it—any admittance to the first makes a conflict. For example:  

var stepSize = 1 

func increment(_ number: inout Int) { 

number += stepSize  

} 

increment(&stepSize) 

//Error: clashing gets to stepSize"

In the code above, stepSize is a global variable, and it is typically open from inside increment(_:). Be that as it may, the read admittance to stepSize covers with the compose admittance to number. One approach to illuminate this contention is to make an express duplicate of stepSize:”  

// Make an explicit copy.

var copyOfStepSize = stepSize

increment(&copyOfStepSize) 

// Update the original.

stepSize = copyOfStepSize

// stepSize is now 2

At the point when you duplicate stepSize prior to calling increment(_:), unmistakably the estimation of copyOfStepSize is increased by the current advance size. The read access closes before the write access begins, so there isn’t a convention.  

Another outcome of long haul compose admittance to in-out parameters is that passing a solitary variable as the argument for various in-out parameters of a similar function creates a contention. For instance:  

func balance(_ x: inout Int, _ y: inout Int) {

    let sum = x + y

    x = sum / 2

    y = sum - x

}

var playerOneScore = 42

var playerTwoScore = 30

balance(&playerOneScore, &playerTwoScore)  // OK

balance(&playerOneScore, &playerOneScore)

// Error: conflicting accesses to playerOneScore

The balance(_:_:) function above adjusts its two parameters to separate the all-out worth uniformly between them. Calling it with playerOneScore and playerTwoScore as contentions doesn’t create a contention—there are two write access to that cover as expected, however, they access various areas in memory. Interestingly, passing playerOneScore as the incentive for the two parameters creates a contention since it attempts to perform two write access to a similar area in memory simultaneously.”