Kas notiks, ja noņemam opcionalus no Swift?

Tas būtu ievērojami samazinājis koda drošību. Daudzas operācijas kļūtu potenciāli nedrošas, jo kompilators nevarētu garantēt vērtības esamību.

1. Optional Chaining (?) un Forced Unwrapping (!) noņemšana. Sintakse darbam ar opcijām kļūtu nederīga.
2. Nepārtraukta nil pārbaude. Izstrādātājiem būtu jāraksta if nosacījumi katrai operācijai ar potenciāli trūkstošu vērtību, kas ievērojami palielinātu boilerplate koda daudzumu un sarežģītību.
3. Paaugstināts avārijas risks. Bez garantijām no kompilatora par vērtības esamību, mēģinājums piekļūt nil novestu pie kļūdas izpildes laikā.
4. Elegantu risinājumu trūkums asinhronitātei. Asinhrono operāciju rezultātu apstrāde, kas var beigties neveiksmīgi (nil), kļūtu sarežģīta.
5. API Objective-C sarežģītība. Daudzas Objective-C metodes atgriež nil, norādot uz neveiksmi vai vērtības neesamību. Savietojamība kļūtu mazāk droša.

Piemēra kods pirms un pēc (hipotētisks):

Pirms:

var optionalString: String? = "Hello"
let length = optionalString?.count // Optional chaining

Pēc (hipotētisks):

var nonOptionalString: String // Tagad visiem mainīgajiem jābūt ar vērtību inicializācijas laikā vai jābūt skaidri pārbaudītiem
var potentiallyNilStringFromSomewhere: String

// Tā vietā, lai izmantotu optional chaining, būtu jāraksta šādi:
if someFunctionCouldReturnNil() {
    // Kļūdas apstrāde
} else {
    potentiallyNilStringFromSomewhere = ... // Vērtības piešķiršana
    let length = potentiallyNilStringFromSomewhere.count // Potenciāls avārija, ja vērtība patiešām ir `nil`
}

// Vai arī tā, ja `nil` joprojām pastāv valodā, bet bez kompilatora atbalsta:
if potentiallyNilStringFromSomewhere != nil {
    let length = potentiallyNilStringFromSomewhere!.count // Bīstama piespiedu iegūšana
} else {
    // `nil` apstrāde
}

Tādējādi, kods kļūtu pakļauts kļūdām izpildes laikā, mazāk lasāms un sarežģītāks uzturēšanai. Opcionalas ir viens no galvenajiem Swift mehānismiem, nodrošinot tipa drošību un cīņu ar Null Pointer Exception.