Коллекции Link to heading

Коллекции элементов являются одними из самых важных типов данных в любом языке программирования. Хорошая поддержка различных видов контейнеров в языке программирования значительно влияет на продуктивность и удовлетворенность программиста. Swift уделяет особое внимание последовательностям и коллекциям — так много из стандартной библиотеки посвящено этой теме, что иногда создается впечатление, что она касается почти ничего другого. Полученная модель более расширяема, чем то, к чему вы, возможно, привыкли в других языках, но она также довольно сложна.

В этой главе мы рассмотрим основные типы коллекций, которые предоставляет Swift, с акцентом на то, как эффективно и идиоматично с ними работать. В главе о протоколах коллекций, которая будет позже в книге, мы поднимемся по лестнице абстракций и увидим, как работают протоколы коллекций в стандартной библиотеке.

Массивы Link to heading

Массивы — это самые распространенные коллекции в Swift. Массив — это упорядоченный контейнер элементов, которые все имеют один и тот же тип, и он предоставляет произвольный доступ к каждому элементу. В качестве примера, чтобы создать массив чисел, мы можем написать следующее:

// Числа Фибоначчи
let fibs = [0, 1, 1, 2, 3, 5]

Массивы и изменяемость Link to heading

Если мы попытаемся изменить массив, определенный выше (например, с помощью append(_:)), мы получим ошибку компиляции. Это происходит потому, что массив определен как константа с помощью let. Во многих случаях это именно то, что нужно; это предотвращает случайные изменения массива. Если мы хотим, чтобы массив был переменной, мы должны определить его с помощью var:

var mutableFibs = [0, 1, 1, 2, 3, 5]

Теперь мы можем легко добавить один элемент или последовательность элементов:

mutableFibs.append(8)  
mutableFibs.append(contentsOf: [13, 21])  
mutableFibs // [0, 1, 1, 2, 3, 5, 8, 13, 21]

Существует несколько преимуществ, связанных с различием между var и let. Константы, определенные с помощью let, легче анализировать, потому что они неизменяемы. Когда вы читаете объявление, такое как let fibs = ..., вы знаете, что значение fibs никогда не изменится — неизменяемость обеспечивается компилятором. Это значительно помогает при чтении кода. Однако обратите внимание, что это верно только для типов, имеющих семантику значений. Переменная let, содержащая ссылку на экземпляр класса, гарантирует, что ссылка никогда не изменится, т.е. вы не можете присвоить другой объект этой переменной. Однако объект, на который указывает ссылка, может измениться. Мы подробнее рассмотрим эти различия в главе о структурах и классах.

Массивы, как и все типы коллекций в стандартной библиотеке, имеют семантику значений. Когда вы присваиваете существующий массив другой переменной, содержимое массива копируется. Например, в следующем фрагменте кода x никогда не изменяется:

var x = [1, 2, 3]  
var y = x  
y.append(4)  
y // [1, 2, 3, 4]  
x // [1, 2, 3]

Утверждение var y = x создает копию x, поэтому добавление 4 в y не изменит x — значение x по-прежнему будет [1, 2, 3]. То же самое происходит, когда вы передаете массив в функцию; функция получает локальную копию массива, и любые изменения, которые она вносит, не влияют на вызывающий код.

Сравните это с подходом к изменяемости, принятым во многих других языках, таких как JavaScript, Java и Objective-C (используя NSArray из Foundation). Массивы в этих языках имеют семантику ссылок: изменение массива через одну переменную неявно изменяет то, что видят все другие переменные, ссылающиеся на тот же массив, потому что все они указывают на одно и то же хранилище. Вот пример на JavaScript:

//'const' делает *переменные* a и b неизменяемыми.
const a = [1, 2, 3];  
const b = a;  
//Но объект, на который они *ссылаются*, все еще изменяемый.
b.push(4);  
console.log(b); // [1, 2, 3, 4]  
console.log(a); // [1, 2, 3, 4]

Правильный способ записать это — вручную создать копию при присваивании:

const c = [1, 2, 3];  
// Создаем явную копию.
const d = c.slice();  
d.push(4);  
console.log(d); // [1, 2, 3, 4]  
console.log(c); // [1, 2, 3]

Забыть об этом легко и подвержено ошибкам. Например, объект, который возвращает массив из своего внутреннего состояния без создания копии, может внезапно нарушить свои инварианты, когда вызывающий код модифицирует массив. Swift избегает этой проблемы, предоставляя коллекциям семантику значений.

Создание копии при каждом присваивании может быть проблемой с производительностью, но на практике все типы коллекций в стандартной библиотеке Swift реализованы с использованием техники, называемой “копирование при записи” (copy-on-write), которая гарантирует, что данные копируются только при необходимости. Таким образом, в нашем примере x и y делили внутреннее хранилище до тех пор, пока не был вызван y.append. В главе о структурах и классах мы более подробно рассмотрим семантику значений — включая то, как реализовать “копирование при записи” для ваших собственных типов.

Индексация Массивов Link to heading

Массивы Swift предоставляют все обычные операции, которые вы ожидаете, такие как isEmpty и count. Массивы также позволяют прямой доступ к элементам по конкретному индексу через подстановку, как в array[3]. Имейте в виду, что вам нужно убедиться, что индекс находится в пределах допустимого диапазона, прежде чем получать элемент через подстановку. Получите элемент по индексу 3, и вы должны быть уверены, что массив содержит как минимум четыре элемента. В противном случае ваша программа завершится с ошибкой, т.е. аварийно завершится с фатальной ошибкой.

В Swift есть много способов работать с массивами, не прибегая к вычислению индекса:

• Хотите пройтись по массиву? for x in array
• Хотите пройтись по всем элементам, кроме первого? for x in array.dropFirst()
• Хотите пройтись по всем элементам, кроме последних пяти? for x in array.dropLast(5)
• Хотите пронумеровать все элементы в массиве? for (num, element) in array.enumerated()
• Хотите пройтись по индексам и элементам вместе? for (index, element) in zip(array.indices, array)
• Хотите найти местоположение конкретного элемента? if let idx = array.firstIndex(where: { someMatchingLogic($0) })
• Хотите преобразовать все элементы в массиве? array.map { someTransformation($0) }
• Хотите получить только элементы, соответствующие определенному критерию? array.filter { someCriteria($0) }

Еще один признак того, что Swift хочет отговорить вас от математических операций с индексами — это отсутствие традиционных циклов for в стиле C в языке. Ручное манипулирование индексами — это богатая почва для ошибок, поэтому это часто лучше избегать.

Но иногда вам действительно нужно использовать индекс. И с индексами массивов ожидается, что, когда вы это делаете, вы очень тщательно обдумали логику, стоящую за вычислением индекса. Поэтому необходимость разыменования значения операции подстановки, вероятно, является избыточной — это означает, что вы не доверяете своему коду. Но, скорее всего, вы доверяете своему коду, поэтому, вероятно, вы прибегнете к принудительному разыменованию результата, потому что знаете, что индекс должен быть действительным. Это (а) раздражает и (б) является плохой привычкой. Когда принудительное разыменование становится рутинным, в конечном итоге вы можете ошибиться и принудительно разыменовать что-то, что не собирались. Чтобы предотвратить эту привычку от становления рутинной, массивы не дают вам такой возможности.

Хотя операция подстановки, которая реагирует на недопустимый индекс контролируемым сбоем, может быть аргументирована как небезопасная, это только один аспект безопасности. Подстановка абсолютно безопасна с точки зрения безопасности памяти — коллекции стандартной библиотеки всегда выполняют проверки границ, чтобы предотвратить несанкционированный доступ к памяти с недопустимым индексом. В Swift термин “безопасность” обычно означает безопасность памяти и избегание неопределенного поведения.

Другие операции ведут себя по-другому. Свойства first и last возвращают опциональное значение, которое равно nil, если массив пуст. first эквивалентно isEmpty ? nil : self[0]. Аналогично, метод removeLast вызовет сбой, если вы вызовете его на пустом массиве, в то время как popLast просто удалит и вернет последний элемент, если массив не пуст, а в противном случае ничего не сделает и вернет nil. Какой из них вы хотите использовать, зависит от вашего случая использования. Когда вы используете массив как стек, вы, вероятно, всегда захотите объединить проверку на пустоту и удаление последнего элемента. С другой стороны, если вы уже знаете, пустой массив или нет, работа с опциональным значением может быть хлопотной.

Мы снова столкнемся с этими компромиссами позже в этой главе, когда будем говорить о словарях. Кроме того, есть целая глава, посвященная опциональным значениям.

Преобразование Массивов Link to heading

map Link to heading

Часто возникает необходимость выполнить преобразование для каждого значения в массиве. Каждый программист писал подобный код сотни раз: создать новый массив, пройтись по всем элементам существующего массива, выполнить операцию над элементом и добавить результат этой операции в новый массив. Например, следующий код возводит в квадрат массив целых чисел:

var squared: [Int] = []
for fib in fibs {
    squared.append(fib * fib)
}
squared // [0, 1, 1, 4, 9, 25]

Массивы Swift имеют метод map, который был заимствован из мира функционального программирования. Вот то же самое действие с использованием map:

let squares = fibs.map { fib in fib * fib }
squares // [0, 1, 1, 4, 9, 25]

Эта версия имеет три основных преимущества. Во-первых, она короче, конечно. Во-вторых, в ней меньше места для ошибок. Но, что более важно, она яснее: весь беспорядок был убран. Как только вы привыкнете видеть и использовать map повсюду, это будет служить сигналом — вы видите map, и вы сразу понимаете, что происходит: функция будет применена к каждому элементу и вернет новый массив преобразованных элементов.

Объявление squares больше не нужно делать с помощью var, потому что мы не мутируем его — он будет возвращен из map полностью сформированным, так что мы можем объявить squares с помощью let, если это уместно. И поскольку тип содержимого может быть выведен из функции, переданной в map, squares больше не нужно явно типизировать.

Метод map несложно написать — это всего лишь вопрос обертывания стандартных частей цикла for в обобщенную функцию. Вот одна из возможных реализаций (хотя в Swift это на самом деле расширение протокола Sequence, который мы рассмотрим в главе о протоколах коллекций):

extension Array {
    func map<T>(_ transform: (Element) -> T) -> [T] {
        var result: [T] = []
        result.reserveCapacity(count)
        for x in self {
            result.append(transform(x))
        }
        return result
    }
}

Element — это обобщенное место для любого типа, который содержит массив, а T — это новое место, представляющее результат преобразования элемента. Функция map сама по себе не заботится о том, что такое Element и T; они могут быть чем угодно. Конкретный тип T преобразованных элементов определяется типом возвращаемого значения функции transform, которую вызывающий передает в map. См. главу о обобщениях для подробностей о обобщенных параметрах.

На самом деле, сигнатура этого метода должна быть:

func map<T>(_ transform: (Element) throws -> T) rethrows -> [T]

Это указывает на то, что map будет перенаправлять любую ошибку, которую может выбросить функция преобразования, вызывающему. Мы подробно рассмотрим это в главе об обработке ошибок, но здесь мы опустили аннотации обработки ошибок ради простоты. Если хотите, вы можете ознакомиться с исходным кодом для Sequence.map в репозитории Swift на GitHub.

Параметризация поведения с помощью функций Link to heading

Даже если вы уже знакомы с map, уделите минуту, чтобы рассмотреть реализацию map. Что делает её такой универсальной и в то же время полезной?
map управляет отделением шаблонного кода — который не меняется от вызова к вызову — от функциональности, которая всегда варьируется, т.е. логики того, как именно преобразовать каждый элемент. Он делает это через параметр, который предоставляет вызывающий код: функцию преобразования.
Этот шаблон параметризации поведения встречается на протяжении всей стандартной библиотеки. Например, существует более дюжины отдельных методов в Array (и других типах коллекций), которые принимают функцию для настройки их поведения:
→ map и flatMap — преобразуют элементы
→ filter — включает только определённые элементы
→ allSatisfy — проверяет все элементы на соответствие условию
→ reduce — сворачивает элементы в агрегированное значение
→ forEach — посещает каждый элемент
→ sort(by:), sorted(by:), lexicographicallyPrecedes(_:by:) и partition(by:) — переупорядочивают элементы
→ firstIndex(where:), lastIndex(where:), first(where:), last(where:) и contains(where:) — существует ли элемент?
→ min(by:) и max(by:) — находят минимум или максимум среди всех элементов
→ elementsEqual(_:by:) и starts(with:by:) — сравнивают элементы с другим массивом
→ split(whereSeparator:) — разбивает элементы на несколько массивов
→ prefix(while:) — берёт элементы с начала, пока условие истинно
→ drop(while:) — отбрасывает элементы, пока условие истинно, а затем возвращает оставшиеся (аналогично prefix, но возвращает обратное)
→ removeAll(where:) — удаляет элементы, соответствующие условию

Цель всех этих функций — избавиться от загромождения неинтересных частей кода, таких как создание нового массива и цикл for по исходным данным. Вместо этого загромождение заменяется одним словом, которое описывает, что делается. Это выдвигает важный код — логику, которую программист хочет выразить — на передний план.
Несколько из этих функций имеют поведение по умолчанию. sort сортирует элементы в порядке возрастания, когда они сравнимы, если не указано иное, а contains может принимать значение для проверки, при условии, что элементы сравнимы. Эти значения по умолчанию помогают сделать код ещё более читаемым. Сортировка по возрастанию естественна, поэтому значение array.sort() интуитивно понятно, а array.firstIndex(of:"foo") яснее, чем array.firstIndex{$0=="foo"}.
Но в каждом случае это просто сокращение для общих случаев. Элементы не обязательно должны быть сравнимыми или эквивалентными, и вам не нужно сравнивать весь элемент — вы можете отсортировать массив людей по их возрасту (people.sort{$0.age<$1.age}) или проверить, содержит ли массив кого-либо несовершеннолетнего (people.contains{$0.age<18}). Вы также можете сравнивать некоторые преобразования элемента. Например, можно выполнить, хотя и неэффективную, сортировку без учета регистра с помощью
people.sort{$0.name.uppercased()<$1.name.uppercased()}.

Существуют и другие функции аналогичной полезности, которые также принимают функцию для указания их поведения, но которые не входят в стандартную библиотеку. Вы можете легко определить их сами (и, возможно, захотите попробовать):
→ accumulate — объединяет элементы в массив текущих значений (как reduce, но возвращает массив каждого промежуточного сочетания)
→ count(where:) — подсчитывает количество элементов, которые соответствуют условию (это должно было быть добавлено в Swift 5.0, но было отложено из-за конфликта имен с свойством count; надеемся, что оно будет повторно введено в следующем релизе)
→ indices(where:) — возвращает список индексов, соответствующих условию (аналогично firstIndex(where:), но не останавливается на первом)

Если вы обнаружите, что итерируете по массиву, чтобы выполнить ту же задачу или аналогичную более чем пару раз в вашем коде, подумайте о том, чтобы написать короткое расширение для Array.
Например, следующий код разбивает массив на группы смежных равных элементов:

let array: [Int] = [1, 2, 2, 2, 3, 4, 4]
var result: [[Int]] = array.isEmpty ? [] : [[array[0]]]
for (previous, current) in zip(array, array.dropFirst()) {
    if previous == current {
        result[result.endIndex-1].append(current)
    } else {
        result.append([current])
    }
}
result // [[1], [2, 2, 2], [3], [4, 4]]

Мы можем формализовать этот алгоритм, абстрагируя код, который проходит по массиву парами смежных элементов, от логики, которая варьируется между приложениями (решение, где разбить массив). Мы используем аргумент функции, чтобы позволить вызывающему коду настроить последнее:

extension Array {
    func split(where condition: (Element, Element) -> Bool) -> [[Element]] {
        var result: [[Element]] = self.isEmpty ? [] : [[self[0]]]
        for (previous, current) in zip(self, self.dropFirst()) {
            if condition(previous, current) {
                result.append([current])
            } else {
                result[result.endIndex-1].append(current)
            }
        }
        return result
    }
}

Это позволяет нам заменить цикл for на следующее:

let parts = array.split { $0 != $1 }
parts // [[1], [2, 2, 2], [3], [4, 4]]

Или, в случае этого конкретного условия, мы можем даже написать:

let parts2 = array.split(where: !=)

Это имеет все те же преимущества, которые мы описали для map. Пример с split(where:) более читаем, чем пример с циклом for; хотя цикл for прост, вам всё равно нужно прокрутить цикл в голове, что является небольшой умственной нагрузкой. Использование split(where:) снижает вероятность ошибки (например, случайно забыв о случае, когда массив пуст), и позволяет вам объявить переменную результата с помощью let, а не var.
Операция split(where:) также является частью пакета SwiftAlgorithms от Apple под названием chunked(by:). SwiftAlgorithms — это библиотека с открытым исходным кодом, содержащая часто используемые операции над коллекциями с высококачественными реализациями. Она предназначена как место с низким уровнем трения для сообщества Swift, чтобы итеративно работать над различными алгоритмами, не проходя сразу высокую планку для добавления в стандартную библиотеку. Функциональность, которая оказывается полезной, может затем мигрировать в стандартную библиотеку позже.
Мы расскажем больше о расширении коллекций и использовании функций позже в книге.

Мутации и состояния замыканий Link to heading

При итерации по массиву вы можете использовать map для выполнения побочных эффектов (например, вставки элементов в некоторую таблицу поиска). Мы не рекомендуем делать это. Посмотрите на следующее:

array.map { item in
    table.insert(item)
}

Это скрывает побочный эффект (мутацию таблицы поиска) в конструкции, которая выглядит как преобразование массива. Если вы когда-либо увидите что-то подобное, это явный случай для использования обычного цикла for вместо функции, такой как map. Метод forEach также будет более уместен, чем map в этом случае, но у него есть свои проблемы, поэтому мы рассмотрим forEach немного позже.

Выполнение побочных эффектов отличается от преднамеренного предоставления замыканию локального состояния, что является особенно полезной техникой. В дополнение к своей полезности, это то, что делает замыкания — функции, которые могут захватывать и изменять переменные вне их области видимости — таким мощным инструментом в сочетании с функциями высшего порядка. Например, функция accumulate, описанная выше, может быть реализована с помощью map и состояния замыкания, следующим образом:

extension Array {
    func accumulate<Result>(_ initialResult: Result, _ nextPartialResult: (Result, Element) -> Result) -> [Result] {
        var running = initialResult
        return map { next in
            running = nextPartialResult(running, next)
            return running
        }
    }
}

Это создает временную переменную для хранения текущего значения и затем использует map для создания массива текущих значений по мере прогресса вычисления:

[1, 2, 3, 4].accumulate(0, +) // [1, 3, 6, 10]

filter Link to heading

Еще одной распространенной операцией является создание нового массива, который включает только те элементы, которые соответствуют определенному условию. Шаблон перебора массива и выбора элементов, соответствующих заданному предикату, зафиксирован в методе filter:

let nums = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
nums.filter { num in num % 2 == 0 } // [2, 4, 6, 8, 10]

Мы можем использовать сокращенную нотацию Swift для аргументов выражения замыкания, чтобы сделать это еще короче. Вместо того чтобы называть аргумент num, мы можем записать приведенный выше код так:

nums.filter { $0 % 2 == 0 } // [2, 4, 6, 8, 10]

Для очень коротких замыканий это может быть более читаемо. Если замыкание более сложное, почти всегда лучше явно называть аргументы, как мы делали ранее. Это действительно вопрос личного вкуса — выбирайте тот вариант, который более читаем на первый взгляд. Хорошее правило: если замыкание помещается аккуратно в одну строку, сокращенные имена аргументов подходят.

Объединив map и filter, мы можем записать множество операций над массивами, не вводя ни одной промежуточной переменной. Получившийся код станет короче и легче для чтения. Например, чтобы найти все квадраты чисел меньше 100, которые четные, мы можем применить map к диапазону 1..<10, чтобы возвести его члены в квадрат, а затем отфильтровать все нечетные числа:

(1..<10).map { $0 * $0 }.filter { $0 % 2 == 0 } // [4, 16, 36, 64]

Реализация filter выглядит аналогично map:

extension Array {
    func filter(_ isIncluded: (Element) -> Bool) -> [Element] {
        var result: [Element] = []
        for x in self where isIncluded(x) {
            result.append(x)
        }
        return result
    }
}

Два быстрых совета по производительности: во-первых, обратите внимание, что цепочка map и filter таким образом создает промежуточный массив (результат операции map), который затем выбрасывается. Это не проблема для нашего небольшого примера, но для больших коллекций или длинных цепочек дополнительные аллокации могут негативно сказаться на производительности. Мы избегаем этих промежуточных массивов, вставив .lazy в начало цепочки, тем самым делая все преобразования ленивыми. Только в конце мы можем преобразовать ленивую коллекцию обратно в обычный массив:

let lazyFilter = (1..<10).lazy.map { $0 * $0 }.filter { $0 % 2 == 0 }
let filtered = Array(lazyFilter) // [4, 16, 36, 64]

Мы поговорим больше о ленивых последовательностях в главе о протоколах коллекций.

Во-вторых, если вы когда-либо окажетесь в ситуации, когда пишете что-то вроде следующего, остановитесь!

bigArray.filter { someCondition }.count > 0

filter создает совершенно новый массив и обрабатывает каждый элемент в массиве. Но это не обязательно. Этот код только должен проверить, соответствует ли один элемент условию — в этом случае contains(where:) выполнит задачу:

bigArray.contains { someCondition }

Это гораздо быстрее по двум причинам: он не создает новый массив отфильтрованных элементов только для того, чтобы посчитать их, и он завершает выполнение раньше — как только находит первое совпадение. В общем, используйте filter только если вам нужны все результаты.

reduce Link to heading

Обе функции map и filter принимают массив и производят новый, модифицированный массив. Однако иногда вы можете захотеть объединить все элементы в одно новое значение. Например, чтобы суммировать все элементы, мы могли бы написать следующий код:

let fibs = [0, 1, 1, 2, 3, 5]
var total = 0
for num in fibs {
    total = total + num
}
total // 12

Метод reduce берет этот шаблон и абстрагирует две части: начальное значение (в данном случае, ноль) и функцию для объединения промежуточного значения (total) и элемента (num). Используя reduce, мы можем записать тот же пример так:

let sum = fibs.reduce(0) { total, num in total + num } // 12

Операторы тоже являются функциями, поэтому мы могли бы также записать тот же пример так:

fibs.reduce(0, +) // 12

Тип выходного значения reduce не обязательно должен совпадать с типом элемента. Например, если мы хотим преобразовать список целых чисел в строку, где каждое число будет следовать за запятой и пробелом, мы можем сделать следующее:

fibs.reduce("") { str, num in str + "\(num), " } // 0, 1, 1, 2, 3, 5,

Вот реализация для reduce:

extension Array {
    func reduce<Result>(_ initialResult: Result,
                        _ nextPartialResult: (Result, Element) -> Result) -> Result {
        var result = initialResult
        for x in self {
            result = nextPartialResult(result, x)
        }

        return result
    }
}

Еще один совет по производительности: reduce очень гибок, и его часто используют для построения массивов и выполнения других операций. Например, вы можете реализовать map и filter, используя только reduce:

extension Array {
    func map2<T>(_ transform: (Element) -> T) -> [T] {
        return reduce([]) {
            $0 + [transform($1)]
        }
    }
    
    func filter2(_ isIncluded: (Element) -> Bool) -> [Element] {
        return reduce([]) {
            isIncluded($1) ? $0 + [$1] : $0
        }
    }
}

Это довольно красиво и имеет преимущество в том, что не требует этих надоедливых императивных циклов for. Но Swift не Haskell, и массивы Swift не являются списками. Что происходит здесь, так это то, что при каждом выполнении функции объединения создается совершенно новый массив, добавляя преобразованный или включенный элемент к предыдущему. Это означает, что обе эти реализации имеют сложность O(n²), а не O(n) — по мере увеличения длины массива время, необходимое для выполнения этих функций, увеличивается квадратично.

Существует вторая версия reduce, которая имеет немного другой тип. Функция редуктора для объединения промежуточного результата и элемента принимает Result в качестве параметра inout:

public func reduce<Result>(into initialResult: Result,
                           _ updateAccumulatingResult:
                           (_ partialResult: inout Result, Element) throws -> ()) rethrows -> Result

Мы подробно обсудим параметры inout в главах о функциях, структурах и классах, но на данный момент подумайте о параметре inout Result как о изменяемом параметре: мы можем модифицировать его внутри функции. Это позволяет нам написать filter гораздо более эффективно:

extension Array {
    func filter3(_ isIncluded: (Element) -> Bool) -> [Element] {
        return reduce(into: []) { result, element in
            if isIncluded(element) {
                result.append(element)
            }
        }
    }
}

При использовании inout компилятор не должен создавать новый массив каждый раз, поэтому эта версия filter снова имеет сложность O(n). Когда вызов reduce(into:_:) инлайнится компилятором, сгенерированный код часто оказывается таким же, как при использовании цикла for.

A Flattening map Link to heading

Иногда вам нужно сопоставить массив, где функция преобразования возвращает другой массив, а не единственный элемент. Например, предположим, что у нас есть функция extractLinks, которая принимает текст в формате Markdown и возвращает массив, содержащий URL всех ссылок в тексте. Подпись функции выглядит следующим образом:

func extractLinks(markdown: String) -> [URL]

Если у нас есть несколько файлов Markdown и мы хотим извлечь ссылки из всех файлов в один массив, мы могли бы попробовать написать что-то вроде markdownFiles.map(extractLinks). Но это вернет массив массивов, содержащих URL: один массив на файл. Теперь вы могли бы просто выполнить map, получить массив массивов, а затем вызвать joined, чтобы объединить результаты в один массив:

let markdownFiles: [String] = // ...
let nestedLinks = markdownFiles.map(extractLinks)
let links = nestedLinks.joined()

Метод flatMap объединяет эти две операции — сопоставление и уплощение — в один шаг. Таким образом, markdownFiles.flatMap(extractLinks) возвращает все URL в массиве файлов Markdown в виде одного массива.

Подпись для flatMap почти идентична map, за исключением того, что функция преобразования возвращает массив. Реализация использует append(contentsOf:) вместо append(_:), чтобы уплотнить результирующий массив:

extension Array {
    func flatMap<T>(_ transform: (Element) -> [T]) -> [T] {
        var result: [T] = []
        for x in self {
            result.append(contentsOf: transform(x))
        }
        
        return result
    }
}

Еще один отличный случай использования flatMap — это объединение элементов из разных массивов. Чтобы получить все возможные пары элементов из двух массивов, используйте flatMap по одному массиву, а затем map по другому в внутренней функции преобразования:

let suits = [" ♠ ", " ♥ ", " ♣ ", " ♦ "]
let ranks = ["J", "Q", "K", "A"]
let result = suits.flatMap { suit in
    ranks.map { rank in
        (suit, rank)
    }
}

/*
[(" ♠ ", "J"), (" ♠ ", "Q"), (" ♠ ", "K"), (" ♠ ", "A"), (" ♥ ", "J"), (" ♥ ",
"Q"), (" ♥ ", "K"), (" ♥ ", "A"), (" ♣ ", "J"), (" ♣ ", "Q"), (" ♣ ", "K"),
(" ♣ ", "A"), (" ♦ ", "J"), (" ♦ ", "Q"), (" ♦ ", "K"), (" ♦ ", "A")]
*/

Итерация с использованием forEach Link to heading

Последняя операция, которую мы хотели бы обсудить, — это forEach. Она работает почти как цикл for: переданная функция выполняется один раз для каждого элемента в последовательности. В отличие от map, forEach ничего не возвращает — она специально предназначена для выполнения побочных эффектов. Давайте начнем с механической замены цикла на forEach:

for element in [1, 2, 3] {
    print(element)
}

[1, 2, 3].forEach { element in
    print(element)
}

Это незначительное улучшение, но оно может быть полезным, если действие, которое вы хотите выполнить, — это единственный вызов функции для каждого элемента в коллекции. Передача имени функции в forEach вместо передачи выражения замыкания может привести к более ясному и лаконичному коду. Например, если вы пишете контроллер представления в iOS и хотите добавить массив подвидов в главное представление, вы можете просто использовать theViews.forEach(view.addSubview).

Однако есть некоторые тонкие различия между циклами for и forEach. Например, если в цикле for есть оператор return, переписывание его с использованием forEach может значительно изменить поведение кода. Рассмотрим следующий пример, который написан с использованием цикла for с условием where:

extension Array where Element: Equatable {
    func firstIndex(of element: Element) -> Int? {
        for idx in self.indices where self[idx] == element {
            return idx
        }
        return nil
    }
}

Мы не можем напрямую воспроизвести условие where в конструкции forEach, поэтому мы можем (неправильно) переписать это с использованием filter:

extension Array where Element: Equatable {
    func firstIndex_foreach(of element: Element) -> Int? {
        self.indices.filter { idx in
            self[idx] == element
        }.forEach { idx in
            return idx
        }
        return nil
    }
}

Оператор return внутри замыкания forEach не возвращает из внешней функции; он возвращает только из самого замыкания. В данном конкретном случае мы, вероятно, нашли бы ошибку, потому что компилятор генерирует предупреждение о том, что аргумент для оператора return не используется, но не стоит полагаться на то, что он найдет каждую такую проблему.

Также рассмотрим следующий пример:

(1..<10).forEach { number in
    print(number)
    if number > 2 { return }
}

Не сразу очевидно, что это выводит все числа в заданном диапазоне. Оператор return не прерывает цикл; скорее, он возвращает из замыкания, тем самым начиная новую итерацию цикла внутри реализации forEach.

В некоторых ситуациях, таких как пример с addSubview выше, forEach может быть удобнее, чем цикл for. Однако из-за неочевидного поведения оператора return мы рекомендуем избегать большинства других случаев использования forEach. Просто используйте обычный цикл for вместо этого.

Array Slices Link to heading

В дополнение к доступу к отдельному элементу массива по индексу (например, fibs[0]), мы также можем получить диапазон элементов по индексу. Например, чтобы получить все элементы массива, кроме первого, мы можем сделать следующее:

let slice = fibs[1...]
slice // [1, 1, 2, 3, 5]
type(of: slice) // ArraySlice<Int>

Это дает нам срез массива, начиная со второго элемента. Тип результата — ArraySlice, а не Array. ArraySlice является представлением массивов. Он основан на оригинальном массиве, но предоставляет представление только на срез. В результате создание среза является дешевым — элементы массива не копируются.

Тип ArraySlice имеет те же методы, что и Array (поскольку оба соответствуют одним и тем же протоколам, наиболее важно — Collection), поэтому вы можете использовать срез так, как если бы это был массив. Если вам нужно преобразовать срез в массив, вы можете просто создать новый массив из среза:

let newArray = Array(slice)  
type(of: newArray) // Array<Int>  

Важно помнить, что срезы всегда используют те же индексы для обращения к конкретному элементу, что и их базовая коллекция. В результате индексы срезов не обязательно начинаются с нуля. Например, первый элемент среза (fibs[1…] , который мы создали выше, находится по индексу 1, и случайный доступ к slice[0] приведет к сбою нашей программы с нарушением границ. Если вы работаете с индексами, мы рекомендуем всегда основывать ваши вычисления на свойствах startIndex и endIndex, даже если вы имеете дело с обычным массивом, где 0 и count-1 также сработают. Это слишком легко для этого неявного предположения сломаться позже. Мы подробно обсудим это свойство срезов в главе о протоколах коллекций.

Dictionaries Link to heading

Другой ключевой структурой данных является Словарь. Словарь содержит уникальные ключи с соответствующими значениями. Извлечение значения по его ключу занимает постоянное время в среднем, в то время как поиск элемента в массиве растет линейно с увеличением размера массива. В отличие от массивов, словари неупорядочены; порядок, в котором пары ключ-значение перечисляются в цикле for, не определен.

В следующем примере мы используем словарь в качестве модели данных для экрана настроек в приложении для смартфона. Экран состоит из списка настроек, и каждая отдельная настройка имеет имя (ключи в нашем словаре) и значение. Значение может быть одним из нескольких типов данных, таких как текст, числа или логические значения. Мы используем перечисление с ассоциированными значениями для моделирования этого:

enum Setting {
    case text(String)
    case int(Int)
    case bool(Bool)
}

let defaultSettings: [String: Setting] = [
    "Режим самолета": .bool(false),
    "Имя": .text("Мой iPhone"),
]

defaultSettings["Имя"] // Optional(Setting.text("Мой iPhone"))

Мы используем сабскрипт для получения значения настройки. Поиск в словаре всегда возвращает опциональное значение — когда указанный ключ не существует, он возвращает nil. Сравните это с массивами, которые реагируют на выход за пределы массива, вызывая сбой программы.

Словари также имеют сабскрипт, который принимает индекс (в отличие от обычно используемого сабскрипта, который принимает ключ) в рамках их соответствия протоколу Collection. Этот сабскрипт вызывает ошибку, когда вызывается с недопустимым индексом, так же как и сабскрипт массива, но он почти никогда не используется (за исключением неявного использования в обобщенных алгоритмах коллекций).

Обоснование этой разницы заключается в том, что индексы массивов и ключи словарей используются очень по-разному. Мы уже видели, что довольно редко вам действительно нужно работать с индексами массивов напрямую. И если вы это делаете, индекс массива обычно прямо выводится из массива каким-либо образом (например, из диапазона, такого как 0..<array.count); таким образом, использование недопустимого индекса является ошибкой программиста. С другой стороны, очень часто ключи словаря приходят из какого-то источника, отличного от самого словаря, который индексируется.

В отличие от массивов, словари также разреженные. Наличие значения под ключом “name” не говорит вам ничего о том, существует ли ключ “address”.

Mutating Dictionaries Link to heading

Так же как и массивы, словари, определенные с помощью let, являются неизменяемыми: в них нельзя добавлять, удалять или изменять записи. И так же, как и с массивами, мы можем определить изменяемый вариант, используя var. Чтобы удалить значение из словаря, мы можем либо установить его в nil, используя подстановку, либо вызвать метод removeValue(forKey:). Последний также возвращает либо удаленное значение, либо nil, если ключа не существовало. Если мы хотим взять неизменяемый словарь и внести в него изменения, нам нужно сделать его копию:

var userSettings = defaultSettings
userSettings["Name"] = .text("iPhone Джареда")
userSettings["Не беспокоить"] = .bool( true )

Обратите внимание, что значение defaultSettings снова не изменилось. Как и при удалении ключа, альтернативой обновлению через подстановку является метод updateValue(_:forKey:), который возвращает предыдущее значение (если таковое имеется):

let oldName = userSettings.updateValue(.text("iPhone Джейн"), forKey: "Name")
userSettings["Name"] // Optional(Setting.text("iPhone Джейн"))
oldName // Optional(Setting.text("iPhone Джареда"))

Некоторые полезные методы Dictionary Link to heading

Что если мы захотим объединить словарь настроек по умолчанию с любыми пользовательскими настройками, которые изменил пользователь? Пользовательские настройки должны переопределять значения по умолчанию, но результирующий словарь все равно должен включать значения по умолчанию для любых ключей, которые не были настроены. По сути, мы хотим объединить два словаря, где словарь, который объединяется, перезаписывает дублирующиеся ключи.

Словарь имеет метод merge(_:uniquingKeysWith:), который принимает пары ключ-значение для объединения и функцию, которая определяет, как комбинировать два значения с одинаковым ключом. Мы можем использовать это для объединения одного словаря в другой, как показано в следующем примере:

var settings = defaultSettings
let overriddenSettings: [String: Setting] = ["Name": .text("iPhone Джейн")]
settings.merge(overriddenSettings, uniquingKeysWith: { $1 })
settings
// ["Name": Setting.text("iPhone Джейн"), "Режим самолета": Setting.bool(false)]

В приведенном выше примере мы использовали { $1 } в качестве политики для комбинирования двух значений. Другими словами, если ключ существует как в settings, так и в overriddenSettings, мы используем значение из overriddenSettings.

Мы также можем создать новый словарь из последовательности пар (Ключ, Значение). Если мы гарантируем, что ключи уникальны, мы можем использовать Dictionary(uniqueKeysWithValues:). Однако, если у нас есть последовательность, где ключ может существовать несколько раз, нам нужно предоставить функцию для комбинирования двух значений для одинаковых ключей, как и выше. Например, чтобы вычислить, как часто элементы появляются в последовательности, мы можем сопоставить каждый элемент, объединить его с 1, а затем создать словарь из получившихся пар элемент-частота. Если мы сталкиваемся с двумя значениями для одного и того же ключа (другими словами, если мы видим один и тот же элемент более одного раза), мы просто складываем частоты, используя +:

extension Sequence where Element: Hashable {
    var frequencies: [Element: Int] {
        let frequencyPairs = self.map { ($0, 1) }
        return Dictionary(frequencyPairs, uniquingKeysWith: +)
    }
}

let frequencies = "hello".frequencies // ["e": 1, "h": 1, "l": 2, "o": 1]
frequencies.filter { $0.value > 1 } // ["l": 2]

Еще один полезный метод — это применение map к значениям словаря. Поскольку Dictionary является последовательностью, у него уже есть метод map, который производит массив. Однако иногда мы хотим сохранить структуру словаря нетронутой и только преобразовать его значения. Метод mapValues делает именно это:

let settingsAsStrings = settings.mapValues { setting -> String in
    switch setting {
    case .text(let text): return text
    case .int(let number): return String(number)
    case .bool(let value): return String(value)
    }
}

settingsAsStrings // ["Name": "iPhone Джейн", "Режим самолета": "false"]

Hashable Requirement for Keys Link to heading

Словари являются хеш-таблицами. Словарь назначает каждой ключевой позиции в своем базовом массиве хранения на основе хеш-значения ключа. Вот почему словарь требует, чтобы его тип ключа соответствовал протоколу Hashable. Все базовые типы данных в стандартной библиотеке — включая строки, целые числа, числа с плавающей запятой и логические значения — уже соответствуют этому протоколу. Кроме того, многие другие типы — такие как массивы, множества и опционалы — автоматически становятся хешируемыми, если их элементы хешируемы.

Чтобы поддерживать свои гарантии производительности, хеш-таблицы требуют, чтобы типы, хранящиеся в них, предоставляли хорошую хеш-функцию, которая не производит слишком много коллизий. Написать хорошую хеш-функцию, которая равномерно распределяет свои входные данные по всему диапазону целых чисел, не так просто. К счастью, нам почти никогда не нужно делать это самостоятельно. Компилятор может сгенерировать соответствие Hashable во многих случаях, и даже если это не сработает для конкретного типа, стандартная библиотека поставляется с встроенной хеш-функцией, к которой могут подключаться пользовательские типы.

Для структур и перечислений Swift может автоматически синтезировать соответствие Hashable для нас, если эти типы сами состоят из хешируемых типов. Если все хранимые свойства структуры хешируемы, то сама структура может быть приведена к Hashable без необходимости писать ручную реализацию. Аналогично, перечисления, которые содержат только хешируемые ассоциированные значения, могут быть приведены к Hashable бесплатно (перечисления без ассоциированных значений даже соответствуют Hashable без явного объявления этого соответствия). Это не только экономит время на начальную реализацию, но и автоматически поддерживает реализацию в актуальном состоянии по мере добавления или удаления свойств.

Если вы не можете воспользоваться автоматической синтезой Hashable (потому что вы пишете класс или ваш пользовательский тип имеет одно или несколько хранимых свойств, которые должны быть проигнорированы для целей хеширования), вам сначала нужно сделать тип Equatable. Затем вы можете реализовать требование hash(into:) протокола Hashable. Этот метод принимает Hasher, который оборачивает универсальную хеш-функцию и захватывает состояние хеш-функции, когда клиенты передают данные в нее. У Hasher есть метод combine, который принимает любое хешируемое значение. Вы должны передать все основные компоненты вашего типа в hasher, передавая их в combine по одному. Основные компоненты — это свойства, которые составляют суть типа; вы обычно захотите исключить временные свойства, которые могут быть воссозданы лениво или которые не видны пользователям типа. Например, Array хранит емкость своего буфера — т.е. максимальное количество элементов, которое он может хранить, прежде чем потребуется перераспределение — внутренне. Но два массива, которые отличаются только емкостью, должны сравниваться и хешироваться одинаково — емкость не является основным компонентом типа Array.

Вы должны использовать одни и те же основные компоненты для проверки равенства, потому что должно выполняться следующее важное инвариант: два экземпляра, которые равны (как определено вашей реализацией ==), должны иметь одинаковое хеш-значение. Обратное не верно: два экземпляра с одинаковым хеш-значением не обязательно сравниваются как равные. Это имеет смысл, учитывая, что существует лишь конечное количество различных хеш-значений, в то время как многие хешируемые типы (например, строки) имеют по сути бесконечную кардинальность.

Универсальная хеш-функция стандартной библиотеки использует случайное семя в качестве одного из своих входов. Другими словами, хеш-значение, скажем, строки “abc” будет отличаться при каждом выполнении программы. Случайное семя является мерой безопасности для защиты от целевых атак типа “отказ в обслуживании” с использованием хеш-флудинга. Поскольку Dictionary и Set итерируют по своим элементам в порядке, в котором они хранятся в хеш-таблице, и поскольку этот порядок определяется хеш-значениями, это означает, что один и тот же код будет производить разные порядки итерации при каждом запуске. Если вам нужно детерминированное хеширование (например, для тестов), вы можете отключить случайное семя, установив переменную окружения SWIFT_DETERMINISTIC_HASHING=1, но не следует делать это в производственной среде.

Наконец, будьте особенно осторожны, когда используете типы, которые не имеют семантики значений (например, изменяемые объекты) в качестве ключей словаря. Если вы измените объект после использования его в качестве ключа словаря таким образом, что изменится его хеш-значение и/или равенство, вы не сможете снова найти его в словаре. Теперь словарь хранит объект в неправильном слоте, фактически повреждая его внутреннее хранилище. Это не проблема для типов значений, потому что ключ в словаре не разделяет хранилище вашей копии и, следовательно, не может быть изменен извне.

Sets Link to heading

Третьим основным типом коллекций в стандартной библиотеке является Множество (Set). Множество — это неупорядоченная коллекция элементов, где каждый элемент появляется только один раз. Вы можете в основном рассматривать множество как словарь, который хранит только ключи и не имеет значений. Как и Словарь (Dictionary), Множество реализовано с помощью хеш-таблицы и имеет аналогичные характеристики производительности и требования. Проверка значения на принадлежность множеству — это операция постоянного времени, и элементы множества должны быть хешируемыми, так же как и ключи словаря.

Используйте множество вместо массива, когда вам нужно эффективно проверять принадлежность (операция O(n) для массивов), и порядок элементов не важен, или когда вам нужно гарантировать, что коллекция не содержит дубликатов.

Множество соответствует протоколу ExpressibleByArrayLiteral, что означает, что мы можем инициализировать его с помощью литерала массива, как показано ниже:

let naturals: Set = [1, 2, 3, 2]
naturals // [1, 2, 3]
naturals.contains(3) // true
naturals.contains(0) // false

Обратите внимание, что число 2 появляется в множестве только один раз; дубликат даже не добавляется.

Как и все коллекции, множества поддерживают общие операции, которые мы уже видели: вы можете перебирать элементы в цикле for, применять к ним map или filter и выполнять множество других операций.

Set Algebra Link to heading

Как следует из названия, Set тесно связан с математической концепцией множества; он поддерживает все общие операции над множествами, которые вы изучали на уроках математики. Например, мы можем вычесть одно множество из другого:

let iPods: Set = ["iPod touch", "iPod nano", "iPod mini", "iPod shuffle", "iPod classic"]  
let discontinuedIPods: Set = ["iPod mini", "iPod classic", "iPod nano", "iPod shuffle"]  
let currentIPods = iPods.subtracting(discontinuedIPods) // ["iPod touch"]  

Мы также можем сформировать пересечение двух множеств, т.е. найти все элементы, которые присутствуют в обоих:

let touchscreen: Set = ["iPhone", "iPad", "iPod touch", "iPod nano"]  
let iPodsWithTouch = iPods.intersection(touchscreen)  
// ["iPod nano", "iPod touch"]  

Или мы можем сформировать объединение двух множеств, т.е. объединить их в одно (удалив дубликаты, конечно):

var discontinued: Set = ["iBook", "PowerBook", "Power Mac"]  
discontinued.formUnion(discontinuedIPods)  
discontinued  
/*  
["iPod classic", "Power Mac", "iPod nano", "iPod shuffle", "iBook",  
"iPod mini", "PowerBook"]  
*/  

Здесь мы использовали мутирующую версию formUnion, чтобы изменить оригинальное множество (которое, как результат, должно быть объявлено с помощью var). Почти все операции над множествами имеют как немутирующие, так и мутирующие формы, и последние имеют префикс form. Для еще большего количества операций над множествами ознакомьтесь с протоколом SetAlgebra.

Использование множеств внутри замыканий Link to heading

Словари и множества могут быть очень полезными структурами данных для использования внутри ваших функций, даже если вы не передаете их вызывающему коду. Например, если мы хотим написать расширение для Sequence, чтобы получить все уникальные элементы в последовательности, мы можем легко поместить элементы в множество и вернуть его содержимое. Однако это не будет стабильным, так как у множества нет определенного порядка, и входные элементы могут быть переупорядочены в результате. Чтобы исправить это, мы можем написать расширение, которое сохраняет порядок, используя внутреннее множество для учета:

extension Sequence where Element: Hashable {
    func unique() -> [Element] {
        var seen: Set<Element> = []
        return filter { element in
            if seen.contains(element) {
                return false
            } else {
                seen.insert(element)
                return true
            }
        }
    }
}

[1, 2, 3, 12, 1, 3, 4, 5, 6, 4, 6].unique() // [1, 2, 3, 12, 4, 5, 6]

Метод выше позволяет нам находить все уникальные элементы в последовательности, при этом сохраняя оригинальный порядок (с условием, что элементы должны быть Hashable). Внутри замыкания, которое мы передаем в filter, мы ссылаемся на переменную seen, которую мы определили вне замыкания, тем самым поддерживая состояние на протяжении нескольких итераций замыкания. В главе о функциях мы рассмотрим эту технику более подробно.

Ranges Link to heading

Range — это интервал значений, который определяется его нижней и верхней границами. Вы создаете диапазоны с помощью двух операторов диапазона: ..< для полузакрытых диапазонов, которые не включают свою верхнюю границу, и ... для закрытых диапазонов, которые включают обе границы: // от 0 до 9, 10 не включен.

let singleDigitNumbers = 0..<10  
Array(singleDigitNumbers) // [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]  
// "z" включен.  
let lowercaseLetters = Character("a")...Character("z")

Также существуют префиксные и постфиксные варианты этих операторов, которые используются для выражения односторонних диапазонов:

let fromZero = 0...  
let upToZ = ..<Character("z")  

Существует пять различных конкретных типов, которые представляют диапазоны, и каждый тип захватывает разные ограничения на значение. Два самых основных типа — это Range (полузакрытый диапазон, созданный с помощью ..<) и ClosedRange (созданный с помощью ...). Оба имеют обобщенный параметр Bound: единственное требование заключается в том, что Bound должен быть Comparable. Например, выражение lowercaseLetters выше имеет тип ClosedRange<Character>.

Самая базовая операция над диапазоном — это проверка, содержит ли он определенные элементы:

singleDigitNumbers.contains(9) // true  
lowercaseLetters.overlaps("c"..<"f") // true  

Существуют отдельные типы для полузакрытых и закрытых диапазонов, потому что у обоих есть свое место:
→ Только полузакрытый диапазон может представлять пустой интервал (когда нижняя и верхняя границы равны, как в 5..<5).
→ Только закрытый диапазон может содержать максимальное значение, которое его тип элемента может представлять (например, 0...Int.max). Полузакрытый диапазон всегда требует как минимум одно представимое значение, которое больше, чем наибольшее значение в диапазоне.

Countable Ranges Link to heading

Диапазоны кажутся естественным выбором для последовательностей или коллекций. И действительно, вы можете перебрать диапазон целых чисел или рассматривать его как коллекцию:

for i in 0..<10 {
    print("\(i)", terminатор: " ")
} // 0 1 2 3 4 5 6 7 8 9

singleDigitNumbers.last // Optional(9)

Но не все диапазоны можно использовать таким образом. Например, компилятор не позволит нам итерировать по диапазону символов:

// Ошибка: Тип 'Character' не соответствует протоколу 'Strideable'.
for c in lowercaseLetters {
    ...
}

(Причина, по которой итерация по символам не так проста, как может показаться, связана с Unicode. Мы подробно рассмотрим эту проблему в главе о строках.)

Что здесь происходит? Диапазон соответствует протоколам коллекции условно, если его тип элементов соответствует протоколу Strideable (т.е. вы можете перейти от одного элемента к другому, добавив смещение) и если шаги шага сами являются целыми числами:

extension Range: Sequence
where Bound: Strideable, Bound.Stride: SignedInteger { /* ... */ }

extension Range: Collection, BidirectionalCollection, RandomAccessCollection
where Bound: Strideable, Bound.Stride: SignedInteger { /* ... */ }

(Мы подробно рассмотрим протоколы Sequence, Collection, BidirectionalCollection и RandomAccessCollection в главе о протоколах коллекций.)

Другими словами, диапазон должен быть счетным, чтобы его можно было итерировать. Допустимые границы для счетных диапазонов (т.е. соответствующие ограничениям) включают целочисленные и указательные типы — но не типы с плавающей запятой, из-за ограничения на целочисленный тип шага. Если вам нужно итерировать по последовательным значениям с плавающей запятой, вы можете использовать функции stride(from:to:by) и stride(from:through:by), чтобы создать такую последовательность.

До того, как условная совместимость с протоколами была введена в Swift 4.1 и 4.2, стандартная библиотека включала конкретные типы с именами CountableRange и CountableClosedRange для различения счетных и несчетных диапазонов. Эти имена все еще существуют как типовые псевдонимы для обратной совместимости. Вы также можете использовать их как сокращение для громоздкого выражения “диапазон плюс ограничения”, как указывает комментарий в стандартной библиотеке:

// Примечание: это не только для совместимости; это считается полезным
// сокращением.
public typealias CountableRange<Bound: Strideable> = Range<Bound>
where Bound.Stride: SignedInteger

Частичные диапазоны (Partial Ranges) Link to heading

Частичные диапазоны создаются с использованием … или ..< в качестве префиксного или постфиксного оператора. Эти диапазоны называются частичными, потому что у них отсутствует одна из границ. Например, 0… описывает диапазон, который начинается с нуля и не имеет верхней границы. Существует три разных типа:

let fromA: PartialRangeFrom<Character> = Character("a")...
let throughZ: PartialRangeThrough<Character> = ...Character("z")
let upto10: PartialRangeUpTo<Int> = ..<10

Таким же образом, как CountableRange является типовым псевдонимом для диапазонов с элементами, которые могут быть шаговыми, CountablePartialRangeFrom является типовым псевдонимом для PartialRangeFrom, но с более строгими ограничениями.

Когда мы итерируемся по счетному PartialRangeFrom, итерация начинается с lowerBound и многократно вызывает advanced(by:1). Если вы используете такой диапазон в цикле for, вы должны позаботиться о добавлении условия выхода, иначе вы можете оказаться в бесконечном цикле (или произойдет сбой, когда счетчик переполнится). PartialRangeThrough и PartialRangeUpTo не могут быть итерированы, независимо от того, являются ли их типы элементов шаговыми или нет, потому что у них обоих отсутствует нижняя граница.

Range Expressions Link to heading

Все пять типов диапазонов соответствуют протоколу RangeExpression. Сам протокол достаточно мал, чтобы его можно было напечатать в этой книге. Он позволяет вам узнать, содержится ли элемент в диапазоне, а также, имея коллекцию, может вычислить полностью определенный диапазон для вас:

public protocol RangeExpression {
    associatedtype Bound: Comparable
    func contains(_ element: Bound) -> Bool
    func relative<C>(to collection: C) -> Range<Bound>
    where C: Collection, Self.Bound == C.Index
}

Для частичных диапазонов с отсутствующей нижней границей метод relative(to:) добавляет startIndex коллекции в качестве нижней границы. Для частичных диапазонов с отсутствующей верхней границей метод будет использовать endIndex коллекции. Частичные диапазоны позволяют использовать очень компактный синтаксис для нарезки коллекций:

let numbers = [1, 2, 3, 4]
numbers[2...] // [3, 4]
numbers[..<1] // [1]
numbers[1...2] // [2, 3]

Это работает, потому что соответствующее объявление подскрипта в протоколе Collection принимает RangeExpression, а не один из пяти конкретных типов диапазонов. Вы даже можете опустить обе границы, чтобы получить срез всей коллекции:

numbers[...] // [1, 2, 3, 4]
type(of: numbers[...]) // ArraySlice<Int>

(Это реализовано как особый случай в стандартной библиотеке. Такой неограниченный диапазон пока не является действительным RangeExpression, но в конечном итоге он должен им стать.)

Если возможно, попробуйте скопировать подход стандартной библиотеки и сделать так, чтобы ваши собственные функции принимали RangeExpression, а не конкретный тип диапазона. Это не всегда возможно, потому что протокол не дает вам доступ к границам диапазона, если вы не находитесь в контексте коллекции, но если это так, вы предоставите пользователям ваших API гораздо больше свободы передавать любые выражения диапазона, которые им нравятся.

Range Set Link to heading

RangeSet — это серия диапазонов одного и того же типа элементов. Его основное применение заключается в упрощении и повышении эффективности работы с разрозненными наборами индексов коллекции. Конечно, вы можете использовать Set для этой задачи, но RangeSet более эффективно использует память, так как может объединять смежные значения в один диапазон. Предположим, у вас есть таблица с 1,000 элементов, и вы хотите использовать набор для управления индексами строк, которые выбрал пользователь. Set должен хранить до 1,000 элементов, в зависимости от того, сколько строк выбрано. С другой стороны, RangeSet хранит смежные диапазоны, поэтому выбор первых 500 строк в таблице требует хранения всего лишь двух целых чисел (нижней и верхней границ выбора).

RangeSet имеет свойство ranges, которое предоставляет интерфейс коллекции для диапазонов:

var indices = RangeSet(1..<5)
indices.insert(contentsOf: 11..<15)
/*show*/ Array(indices.ranges)

Диапазоны всегда возвращаются в порядке возрастания, независимо от порядка вставки, и они никогда не перекрываются и не соприкасаются. Если вы предпочитаете коллекцию отдельных элементов, используйте flatMap:

/*show*/ Array(indices.ranges.flatMap { $0 })
/*show*/ let evenIndices = indices.ranges
    .flatMap { $0 }
    .filter { $0 % 2 == 0 }

RangeSet не соответствует протоколу SetAlgebra, но реализует подмножество операций SetAlgebra для формирования объединений, пересечений и т.д.

Тип RangeSet еще не является частью стандартной библиотеки, но он прошел через процесс Swift Evolution как предложение SE-0270. В настоящее время он доступен как часть пакета Standard Library Preview, который служит “площадкой для испытаний” для новых дополнений в стандартную библиотеку, позволяя быстро адаптироваться и обеспечивая реальный период тестирования, в течение которого все еще могут быть внесены разрушительные изменения.

Резюме Link to heading

В этой главе мы обсудили несколько различных коллекций: массивы, словари, множества и диапазоны. Мы также рассмотрели ряд операций, которые доступны для каждой из этих коллекций, и как писать мощные алгоритмы, комбинируя эти операции. Мы увидели, как встроенные коллекции Swift позволяют контролировать изменяемость с помощью let и var, а также как разобраться во всех различных типах диапазонов.

По сравнению с другими языками, стандартная библиотека Swift предлагает относительно немного универсальных типов коллекций. Если вам не хватает какой-либо конкретной структуры данных, обратите внимание на пакет Swift Collections, где члены команды стандартной библиотеки и остальное сообщество Swift работают над высококачественными реализациями для общих структур данных, таких как двусторонняя очередь и упорядоченные варианты Set и Dictionary.

Строки также являются коллекциями. Мы не обсуждали их здесь, потому что им посвящена отдельная глава.

Мы вернемся к теме этой главы в разделе о Протоколах Коллекций, где мы подробно обсудим протоколы, на которых основаны коллекции Swift.

Опциональные параметры Link to heading

3 Link to heading

Sentinel Values Link to heading

Одним из крайне распространенных паттернов в программировании является наличие операции, которая может или не может вернуть значение. Возможно, отсутствие возвращаемого значения является ожидаемым результатом, когда вы достигли конца файла, который читали, как в следующем фрагменте на C:

int ch;
while ((ch=getchar())!=EOF) {
    printf("Read character %c\n", ch);
}
printf("Reached end-of-file\n");

EOF — это просто определение для -1. Пока в файле есть символы, getchar возвращает их. Но если конец файла достигнут, getchar возвращает -1.

Или, возможно, отсутствие возвращаемого значения означает «не найдено», как в этом фрагменте на C++:

auto vec = {1, 2, 3};
auto iterator = std::find(vec.begin(), vec.end(), someValue);
if (iterator != vec.end()) {
    std::cout << "vec contains " << *iterator << std::endl;
}

Здесь vec.end() — это итератор «один после конца» контейнера; это специальный итератор, который вы можете проверить на соответствие концу контейнера, но который вы никогда не должны использовать для доступа к значению — аналогично индексу конца коллекции в Swift. Функция find использует его, чтобы указать, что такого значения в контейнере нет.

Или, возможно, значение не может быть возвращено, потому что что-то пошло не так во время обработки функции. Вероятно, самым известным примером является нулевой указатель. Этот на вид безобидный фрагмент кода на Java, скорее всего, вызовет NullPointerException:

int i = Integer.getInteger("123");

Дело в том, что Integer.getInteger не разбирает строки в целые числа, а получает целочисленное значение системного свойства с именем «123». Это свойство, вероятно, не существует, в этом случае getInteger возвращает null. Когда null затем распаковывается в int, Java выбрасывает исключение.

Или возьмите этот пример на Objective-C:

[[NSString alloc] initWithContentsOfURL:url encoding:NSUTF8StringEncoding error:&error];

Этот инициализатор может вернуть nil, в этом случае — и только тогда — указатель на ошибку должен быть проверен. Нет гарантии, что указатель на ошибку действителен, если инициализатор возвращает не nil.

Во всех вышеперечисленных примерах функция возвращает специальное «магическое» значение, чтобы указать, что она не вернула реальное значение. Магические значения, подобные этим, называются «сентинельными значениями».

Но этот подход проблематичен. Возвращенный результат выглядит и ощущается как реальное значение. int со значением -1 все еще является допустимым целым числом, но вы никогда не хотите его выводить. vec.end() — это итератор, но результаты неопределены, если вы попытаетесь его использовать. И всем нравится видеть дамп стека, когда ваша Java-программа выбрасывает NullPointerException.

В отличие от Java, Objective-C позволяет отправлять сообщения nil. Это «безопасно» в том смысле, что среда выполнения гарантирует, что возвращаемое значение от сообщения к nil всегда будет эквивалентно нулю, т.е. nil для типов объектов, 0 для числовых типов и так далее. Если сообщение возвращает структуру, все ее члены будут инициализированы нулем. Учитывая это, рассмотрим следующий фрагмент для поиска подстроки:

NSString *someString = ...;
if ([someString rangeOfString:@"Swift"].location != NSNotFound) {
    NSLog(@"Someone mentioned Swift!");
}

Если someString равно nil, случайно или намеренно, сообщение rangeOfString: вернет инициализированный NSRange. Следовательно, его .location будет равен нулю, и неравенство по сравнению с NSNotFound (который определен как NSIntegerMax) будет выполнено успешно. Таким образом, тело оператора if будет выполнено, когда этого не должно быть.

Нулевые ссылки вызывают так много проблем, что Тони Хоар, которому приписывают их создание в 1965 году, называет их своей «миллиардной долларовой ошибкой»:

В то время я разрабатывал первую комплексную систему типов для ссылок в объектно-ориентированном языке (ALGOL W). Моя цель заключалась в том, чтобы гарантировать, что все использование ссылок должно быть абсолютно безопасным, с проверкой, выполняемой автоматически компилятором. Но я не мог устоять перед искушением вставить нулевую ссылку, просто потому что это было так легко реализовать. Это привело к бесчисленным ошибкам, уязвимостям и сбоям системы, которые, вероятно, вызвали миллиард долларов боли и ущерба за последние сорок лет.

Еще одной проблемой с сентинельными значениями является то, что их правильное использование требует предварительных знаний. Иногда существует идиома, которая широко соблюдается в сообществе, как, например, итератор конца в C++ или соглашения по обработке ошибок в Objective-C. Если таких правил не существует или вы о них не знаете, вам придется обращаться к документации. Более того, нет способа для функции указать, что она не может завершиться успешно. Если вызов возвращает указатель, этот указатель может никогда не быть nil. Но нет способа это узнать, кроме как прочитать документацию, и даже тогда документация может быть неверной.

Замена значений-сентинелов на перечисления Link to heading

Конечно, каждый хороший программист знает, что магические числа — это плохо. Большинство языков поддерживают какой-то вид перечисляемого типа, который является более безопасным способом представления набора дискретных возможных значений для типа. Swift развивает концепцию перечислений с помощью “ассоциированных значений”. Это значения перечисления, которые также могут иметь другое значение, связанное с ними. Мы подробно рассмотрим перечисления в главе о перечислениях. На данный момент достаточно знать, что Optional определяется как перечисление:

enum Optional<Wrapped> {
    case none
    case some(Wrapped)
}

Единственный способ получить ассоциированное значение перечисления — это с помощью сопоставления с образцом, например, в операторе switch или в операторе if case let. Кодирование состояния “отсутствующего значения” в системе типов делает код более выразительным, потому что вызывающие API могут сразу увидеть, нужно ли им обрабатывать этот случай. И в отличие от значения-сентинела, вы не можете случайно использовать значение, встроенное в Optional, не проверив и не распаковав его явно.

Таким образом, вместо возврата значения-сентинела, эквивалент Swift для nil — это метод firstIndex(of:), который возвращает Optional<Index> с реализацией, несколько похожей на эту:

extension Collection where Element: Equatable {
    func firstIndex(of element: Element) -> Optional<Index> {
        var idx = startIndex
        while idx != endIndex {
            if self[idx] == element {
                return .some(idx)
            }
            formIndex(after: &idx)
        }
        // Не найдено, возвращаем .none.
        return .none
    }
}

Поскольку опционалы являются основополагающими для Swift, существует много синтаксической поддержки для упрощения этого: Optional<Index> можно записать как Index?; опционалы соответствуют протоколу ExpressibleByNilLiteral, так что вы можете писать nil вместо .none; и не-опциональные значения (например, idx) автоматически “продвигаются” до опционалов, когда это необходимо, так что вы можете писать return idx вместо return .some(idx).

Синтаксический сахар эффективно скрывает истинную природу типа Optional. Стоит помнить, что в этом нет ничего магического; это просто обычное перечисление, и если бы его не существовало, вы могли бы определить его сами.

Теперь нет способа, чтобы пользователь случайно использовал значение, не проверив, действительно ли оно валидно:

var array = ["one", "two", "three"]
let idx = array.firstIndex(of: "four") // возвращает Optional<Int>.
// Ошибка компиляции: remove(at:) принимает Int, а не Optional<Int>.
array.remove(at: idx)

Вместо этого вам придется “распаковать” опционал, чтобы получить индекс внутри, предполагая, что вы не получили none:

var array = ["one", "two", "three"]
switch array.firstIndex(of: "four") {
case .some(let idx):
    array.remove(at: idx)
case .none:
    break // Ничего не делать.
}

Этот оператор switch записывает синтаксис перечисления для опционалов в полном виде, включая распаковку ассоциированного значения в случае some. Это отлично для безопасности, но не очень приятно для чтения или написания. Более лаконичной альтернативой является использование суффикса ? для сопоставления с некоторым опциональным значением, и вы можете использовать литерал nil для сопоставления с none:

switch array.firstIndex(of: "four") {
case let idx?: // Эквивалентно .some(let idx)
    array.remove(at: idx)
case nil:
    break // Ничего не делать.
}

Но это все еще громоздко. Давайте рассмотрим все другие способы, которыми вы можете сделать обработку опционалов короткой и ясной, в зависимости от вашего случая использования.

Обзор дополнительных техник Link to heading

Опционалы имеют много дополнительных возможностей, встроенных в язык. Некоторые из приведенных ниже примеров могут показаться очень простыми, если вы уже какое-то время пишете на Swift, но важно убедиться, что вы хорошо понимаете все эти концепции, так как мы будем использовать их снова и снова на протяжении всей книги.

if let Link to heading

Привязка опциональных значений с помощью if let — это всего лишь шаг от оператора switch, описанного выше. Оператор if let проверяет, является ли опциональное значение ненулевым, и если это так, он извлекает опциональное значение. Тип idx — это Int (неопциональный), и idx доступен только в пределах области видимости оператора if let:

var array = ["one", "two", "three", "four"]
if let idx = array.firstIndex(of: "four") {
    array.remove(at: idx)
}

Вы также можете использовать логические условия вместе с if let. Предположим, вы не хотите удалять элемент, если он оказался первым в массиве:

if let idx = array.firstIndex(of: "four"), idx != array.startIndex {
    array.remove(at: idx)
}

Вы также можете привязывать несколько значений в одном операторе if. Более того, последующие значения могут полагаться на успешное извлечение предыдущих. Это очень полезно, когда вы хотите сделать несколько вызовов функций, которые сами возвращают опциональные значения. Например, инициализаторы URL и UIImage в следующем примере являются “неудачными” — то есть они могут вернуть nil, если ваш URL неправильно сформирован или если данные не являются изображением. Инициализатор Data может выбросить ошибку, и, используя try?, вы можете преобразовать его в опциональное значение. Все три можно связать вместе, как это:

let urlString = "https://www.objc.io/logo.png"
if let url = URL(string: urlString),
   let data = try? Data(contentsOf: url),
   let image = UIImage(data: data) {
      let view = UIImageView(image: image)
      PlaygroundPage.current.liveView = view
   }

Синхронный инициализатор Data(contentsOfURL:) будет блокировать свой поток на время загрузки. Это нормально для быстрого примера, но не рекомендуется для производственного кода. Всегда используйте асинхронный сетевой API, такой как URLSession.data(from:delegate:).

Вы можете свободно комбинировать и сочетать привязки опциональных значений, логические условия и привязки case let в одном операторе if.

while let Link to heading

Очень похоже на оператор if let, while let — это цикл, который завершается, когда его условие возвращает nil. Функция readLine стандартной библиотеки возвращает необязательную строку из стандартного ввода. Как только конец ввода достигнут, она возвращает nil. Чтобы реализовать очень базовый эквивалент команды Unix cat, вы используете while let:

while let line = readLine() {
    print(line)
}

Так же, как и в операторах if let, вы всегда можете добавить логическое условие к вашему необязательному связыванию. Поэтому, если вы хотите завершить этот цикл при достижении EOF или пустой строки, добавьте условие для обнаружения пустой строки. Обратите внимание, что как только условие становится false, цикл завершается (вы можете ошибочно думать, что логическое условие работает как фильтр):

while let line = readLine(), !line.isEmpty {
    print(line)
}

Как мы увидим в главе о протоколах коллекций, цикл for-in seq требует, чтобы seq соответствовал протоколу Sequence. Этот протокол предоставляет метод makeIterator, который возвращает итератор, который, в свою очередь, имеет метод next. Метод next возвращает значения, пока последовательность не исчерпана, а затем возвращает nil. whilelet идеально подходит для этого:

let array = [1, 2, 3]
var iterator = array.makeIterator()
while let i = iterator.next() {
    print(i, terminator: " ")
} // 1 2 3

Таким образом, учитывая, что циклы for на самом деле являются просто циклами while, неудивительно, что они также поддерживают логические условия, хотя и с ключевым словом where:

for i in 0..<10 where i % 2 == 0 {
    print(i, terminator: " ")
} // 0 2 4 6 8

Обратите внимание, что условие where выше не работает так же, как логическое условие в цикле while. В цикле while итерация останавливается, как только значение становится false, в то время как в цикле for оно функционирует как фильтр. Если бы мы переписали вышеуказанный цикл for, используя while, это выглядело бы так:

var iterator2 = (0..<10).makeIterator()
while let i = iterator2.next() {
    guard i % 2 == 0 else { continue }
    print(i)
}

Doubly Nested Optionals Link to heading

Это хорошее время, чтобы указать на то, что тип, который может быть опциональным, может сам по себе быть опциональным, что приводит к опционалам, вложенным внутри опционалов. Чтобы понять, почему это не просто странный крайний случай или что-то, что компилятор должен автоматически объединить, предположим, что у вас есть массив строк, представляющих числа, которые вы хотите преобразовать в целые числа. Вы можете пропустить их через map, чтобы преобразовать их:

let stringNumbers = ["1", "2", "three"]
let maybeInts = stringNumbers.map { Int($0) } // [Optional(1), Optional(2), nil]

Теперь у вас есть массив Optional<Int> — т.е. Int? — потому что Int.init(String) может завершиться неудачей, так как строка может не содержать допустимого целого числа. Здесь последний элемент будет nil, так как “three” не является целым числом.

При переборе массива с помощью for вы бы справедливо ожидали, что каждый элемент будет опциональным целым числом, потому что именно это и содержит maybeInts:

for maybeInt in maybeInts {
    // maybeInt is an Int?
    // Два числа и `nil`.
}

Теперь рассмотрим, что реализация for...in является сокращением для техники цикла while, описанной выше. То, что возвращается из iterator.next(), будет Optional<Optional<Int>> — или Int?? — потому что next оборачивает каждый элемент в последовательности внутри опционала. while let распаковывает его, чтобы проверить, что это не nil, и пока это не nil, связывает распакованное значение и выполняет тело:

var iterator = maybeInts.makeIterator()
while let maybeInt = iterator.next() {
    print(maybeInt, terminator: " ")
}
// Optional(1) Optional(2) nil

Когда цикл доходит до последнего элемента — nil от “three” — то, что возвращается из next, является ненулевым значением: .some(nil). Это распаковывается и связывает то, что внутри (т.е. nil), с maybeInt. Без вложенных опционалов это было бы невозможно.

Кстати, если вы когда-либо захотите перебрать только ненулевые значения с помощью for, вы можете использовать сопоставление с образцом:

for case let i? in maybeInts {
    // i будет Int, а не Int?
    print(i, terminator: " ")
}
// 1 2

Или только nil значения:

for case nil in maybeInts {
    // Будет выполнено один раз для каждого nil.
    print("No value")
}
// No value

Это использует “шаблон” x?, который соответствует только ненулевым значениям. Это сокращение для .some(x), так что цикл можно было бы записать так:

for case let .some(i) in maybeInts {
    print(i)
}

Это основанное на случае сопоставление с образцом — это способ применения тех же правил, которые работают в операторе switch, к if, for и while. Это наиболее полезно с опционалами, но также имеет и другие применения — например:

let j = 5
if case 0..<10 = j {
    print("\(j) within range")
} // 5 within range

Мы подробно обсудим сопоставление с образцом в главе о перечислениях.

if var and while var Link to heading

Вместо let вы можете использовать var с if, while и for. Это позволяет вам изменять переменную внутри тела оператора:

let number = "1"  
if var i = Int(number) {  
    i += 1  
    print(i)  
} // 2  

Но обратите внимание, что i будет локальной копией; любые изменения i не повлияют на значение внутри оригинального опционала. Опционалы являются типами значений, и разыменование их копирует значение внутри.

Область видимости необернутых опционалов Link to heading

Иногда ограничивает, что доступ к необернутой переменной возможен только внутри блока if, в котором она была определена. Например, рассмотрим свойство first для массивов — свойство, которое возвращает опционал первого элемента или nil, когда массив пуст. Это удобный сокращенный вариант для следующего распространенного кода:

let array = [1, 2, 3]
if !array.isEmpty {
    print(array[0])
}
// За пределами блока компилятор не может гарантировать, что array[0] действителен.

Использование свойства first предпочтительнее, потому что вам нужно развернуть опционал, чтобы использовать его — вы не можете случайно забыть:

if let firstElement = array.first {
    print(firstElement)
}
// За пределами блока вы не можете использовать firstElement.

Необернутое значение доступно только внутри блока if let. Это здорово, но это непрактично, если цель оператора if — выйти из функции, когда не выполнено какое-то условие. Этот ранний выход может помочь избежать надоедливой вложенности или повторных проверок позже в функции. Вы можете написать следующее:

func doStuff(withArray a: [Int]) {
    if a.isEmpty {
        return
    }
    // Теперь используйте a[0] или a.first! безопасно.
}

Здесь связывание if let не сработает, потому что связанная переменная не будет в области видимости после блока if. Но вы все равно можете быть уверены, что массив будет содержать хотя бы один элемент, поэтому принудительное развертывание первого элемента безопасно, даже если синтаксис все еще не привлекателен.

Одним из вариантов использования необернутого опционала за пределами области, в которой он был связан, является полагание на возможности отложенной инициализации Swift. Рассмотрим следующий пример, который повторно реализует часть свойства pathExtension из URL и NSString:

extension String {
    var fileExtension: String? {
        let period: String.Index
        if let idx = lastIndex(of: ".") {
            period = idx
        } else {
            return nil
        }
        let extensionStart = index(after: period)
        return String(self[extensionStart...])
    }
}

"hello.txt".fileExtension // Optional("txt")

Компилятор проверяет ваш код, чтобы подтвердить, что есть только два возможных пути: один, в котором функция возвращает значение раньше, и другой, где period правильно инициализирован. Никак не может быть, чтобы period был nil (он не опционален) или не инициализирован (Swift не позволит вам использовать переменную, которая не была инициализирована). Поэтому после оператора if код может быть написан без необходимости беспокоиться об опционалах.

Тем не менее, два предыдущих примера довольно неуклюжи. На самом деле, что нужно, так это нечто вроде if not let — что именно и делает guard let:

func doStuff(withArray a: [Int]) {
    guard let firstElement = a.first else {
        return
    }
    // firstElement здесь развернут.
}

И второй пример становится гораздо яснее:

extension String {
    var fileExtension: String? {
        guard let period = lastIndex(of: ".") else {
            return nil
        }
        let extensionStart = index(after: period)
        return String(self[extensionStart...])
    }
}

В блок else здесь может входить все, включая несколько операторов, как в if...else. Единственное требование заключается в том, что блок else должен покинуть текущую область видимости. Это может означать return, выброс ошибки или вызов fatalError (или любой другой функции, которая возвращает Never). Если бы guard находился в цикле, break или continue также были бы допустимы.

Функция с типом возвращаемого значения Never сигнализирует компилятору, что она никогда не вернется. Существуют два распространенных типа функций, которые делают это: те, которые прерывают программу, такие как fatalError; и те, которые работают на протяжении всей жизни программы, как dispatchMain. Компилятор использует эту информацию для своей диагностики управления потоком. Например, ветвь else оператора guard должна либо покинуть текущую область видимости, либо вызвать одну из функций, которые никогда не возвращаются.

Never — это то, что называется необитаемым типом. Это тип, у которого нет допустимых значений и, следовательно, не может быть сконструирован. Функция, объявленная для возврата необитаемого типа, никогда не может вернуть значение нормально.

В Swift необитаемый тип реализован как enum, который не имеет случаев:

public enum Never { }

Обычно вам не нужно определять свои собственные функции, которые никогда не возвращаются, если только вы не пишете обертку для fatalError или preconditionFailure. Один интересный случай использования возникает, когда вы пишете новый код: скажем, вы работаете над сложным оператором switch, постепенно заполняя все случаи, и компилятор забрасывает вас сообщениями об ошибках из-за пустых меток случаев или отсутствующих значений возврата, в то время как все, что вы хотите сделать, — это сосредоточиться на одном случае, над которым вы работаете. В этой ситуации несколько тщательно размещенных вызовов fatalError() могут творить чудеса, чтобы заставить компилятор замолчать. Рассмотрите возможность написания функции с именем unimplemented(), чтобы лучше передать временный характер этих вызовов:

func unimplemented() -> Never {
    fatalError("Этот код еще не реализован.")
}

Never также часто используется в сочетании с Result и подобными типами в обобщенных контекстах. Например, рассмотрим фреймворк реактивного программирования, такой как Combine от Apple. Combine моделирует потоки событий с помощью протокола Publisher с двумя связанными типами: Output и Failure. Output описывает тип полезной нагрузки эмитируемого события, в то время как Failure представляет случай ошибки.

Объект текстового поля может предоставить AnyPublisher<String, Never>, который генерирует событие каждый раз, когда пользователь редактирует текст. Использование Never в качестве типа ошибки указывает программисту и компилятору, что этот издатель никогда не будет генерировать ошибку, поскольку такое значение невозможно сконструировать.

Swift тщательно различает разные виды “ничто”. В дополнение к nil и Never, есть также Void, который является другим способом записи пустого кортежа:

public typealias Void = ()

Наиболее распространенное использование Void или () — это типы функций, которые ничего не возвращают, но у него есть и другие применения. Например, издатель для объекта кнопки будет генерировать событие, когда пользователь нажимает на кнопку, но у него нет дополнительной полезной нагрузки для отправки — его поток событий должен иметь тип AnyPublisher<(), Never>.

Как сказал Дэвид Смит, Swift делает четкое различие между “отсутствием вещи” (nil), “присутствием ничего” (Void) и “вещью, которая не может быть” (Never).

Так же, как и if, guard не ограничивается только связыванием. guard может принимать любое условие, которое вы можете найти в обычном операторе if, поэтому пример с пустым массивом можно переписать с его использованием:

func doStuff2(withArray a: [Int]) {
    guard !a.isEmpty else { return }
    // Теперь используйте a[0] или a.first! безопасно.
}

В отличие от случая связывания опционала, этот guard не является большим выигрышем — на самом деле, он немного более многословен, чем оригинальная версия. Но все же стоит рассмотреть возможность использования этого в любой ситуации с ранним выходом. Во-первых, иногда (хотя не в этом случае) инверсия логического условия может сделать вещи более ясными. Кроме того, guard является четким сигналом при чтении кода. Он говорит: “Мы продолжаем только в том случае, если выполняется следующее условие.” Наконец, компилятор Swift проверит, что вы определенно покидаете текущую область видимости, и вызовет ошибку компиляции, если вы этого не сделаете. По этой причине мы рекомендуем использовать guard, даже когда if мог бы сработать.

Optional Chaining Link to heading

В Objective-C отправка сообщения nil не приводит к ошибке. В Swift тот же эффект можно достичь с помощью “опциональной цепочки”:

delegate?.callback()

В отличие от Objective-C, компилятор Swift заставит вас признать, что получатель может быть nil. Знак вопроса является ясным сигналом для читателя о том, что метод может не быть вызван.

Когда метод, который вы вызываете через опциональную цепочку, возвращает результат, этот результат также будет опциональным. Рассмотрим следующий код, чтобы понять, почему это должно быть так:

let str: String? = "Never say never"
// Мы хотим, чтобы upper был строкой в верхнем регистре.
let upper: String
if str != nil {
    upper = str!.uppercased()
} else {
    // На данном этапе нет разумного действия.
    fatalError("Не знаю, что делать дальше...")
}

Если str не равен nil, upper будет иметь желаемое значение. Но если str равен nil, то upper не может быть установлен в значение. Поэтому в случае опциональной цепочки upper2 должен быть опциональным, чтобы учесть возможность, что str мог быть nil:

let upper2 = str?.uppercased() // Optional("NEVER SAY NEVER")

Вы не ограничены одним вызовом метода после знака вопроса. Как подразумевает термин “опциональная цепочка”, вы можете связывать вызовы для опциональных значений:

let lower = str?.uppercased().lowercased() // Optional("never say never")

Это может показаться немного удивительным. Разве мы только что не сказали, что результат опциональной цепочки является опциональным? Так почему же вам не нужен знак вопроса после uppercased()? Это связано с тем, что опциональная цепочка является операцией “уплощения”. Если str?.uppercased() возвращает опциональное значение, и мы вызываем ?.lowercased() на нем, то логически мы получили бы опциональное опциональное значение. Но мы просто хотим обычное опциональное значение, поэтому вместо этого мы пишем второй связанный вызов без знака вопроса, чтобы отразить тот факт, что опциональность уже захвачена.

С другой стороны, если метод uppercased сам возвращает опциональное значение, тогда нам нужно добавить второй знак вопроса, чтобы выразить, что мы связываем это опциональное значение. Например, давайте расширим тип Int с вычисляемым свойством, названным half. Это свойство возвращает результат деления целого числа на два, но только если число достаточно велико для деления. Когда число меньше двух, оно возвращает nil:

extension Int {
    var half: Int? {
        guard self < -1 || self > 1 else { return nil }
        return self / 2
    }
}

Поскольку вызов half возвращает опциональный результат, нам нужно продолжать добавлять знак вопроса при его повторном вызове. В конце концов, на каждом шаге функция может вернуть nil:

20.half?.half?.half // Optional(2)

Обратите внимание, что компилятор все еще достаточно умен, чтобы уплощать тип результата для нас. Тип выражения выше — Int?, а не Int??? , как вы могли бы ожидать. Последний вариант дал бы вам больше информации — а именно, какая часть цепочки не удалась — но это также сделало бы гораздо более громоздким работу с результатом, разрушая удобство, которое добавляет опциональная цепочка изначально.

До сих пор мы видели опциональную цепочку для вызовов методов и доступа к свойствам. Она также применяется к подскриптам — например:

let dictOfArrays = ["nine": [0, 1, 2, 3]]
dictOfArrays["nine"]?[3] // Optional(3)

Кроме того, вы можете использовать опциональную цепочку для вызова опциональных функций:

let dictOfFunctions: [String: (Int, Int) -> Int] = [
    "add": (+),
    "subtract": (-)
]
dictOfFunctions["add"]?(1, 1) // Optional(2)

Это удобно в типичных ситуациях обратного вызова, когда класс хранит функцию обратного вызова, чтобы информировать своего владельца, когда происходит событие. Рассмотрим класс TextField:

class TextField {
    private(set) var text = ""
    var didChange: ((String) -> ())?
    // Обработчик событий, вызываемый фреймворком.
    func textDidChange(newText: String) {
        text = newText
        // Вызов обратного вызова, если он не nil.
        didChange?(text)
    }
}

Свойство didChange хранит функцию обратного вызова, которую текстовое поле вызывает каждый раз, когда пользователь редактирует текст. Поскольку владелец текстового поля не обязан регистрировать обратный вызов, это свойство является опциональным; его начальное значение — nil. Когда приходит время вызвать обратный вызов (в методе textDidChange выше), опциональная цепочка позволяет нам сделать это очень компактным способом.

Опциональные переменные (не let) неявно инициализируются в nil, если вы не присваиваете значение. Это единственное исключение, которое Swift делает из своей строгой политики явной инициализации. Обоснование этого — удобство, и у опционалов есть “очевидное” значение по умолчанию. Тем не менее, некоторые члены команды Swift выразили сожаление по поводу этого дизайнерского решения и предпочли бы изменить его, если бы это не сломало существующий код. Любопытно, что неявная инициализация срабатывает только для объявлений, которые используют …? сокращение для аннотации типа. Если бы мы написали var didChange: Optional<(String) -> ()> выше, компилятор пожаловался бы, что свойство не было инициализировано.

Опциональная цепочка и присваивания Link to heading

Вы даже можете присваивать значения через опциональную цепочку. Предположим, у вас есть опциональная переменная, и если она не равна nil, вы хотите обновить одно из её свойств:

struct Person {
    var name: String
    var age: Int
}

var optionalLisa: Person? = Person(name: "Лиза Симпсон", age: 8)
// Увеличиваем возраст, если он не равен nil.
if optionalLisa != nil {
    optionalLisa!.age += 1
}

Это довольно многословно и неуклюже. Обратите внимание, что вы не можете использовать опциональное связывание в этом случае. Поскольку Person — это структура и, следовательно, тип значения, связанная переменная является локальной копией оригинального значения; изменение первой не изменит последнюю:

if var lisa = optionalLisa {
    // Изменение lisa не изменяет optionalLisa.
    lisa.age += 1
}

Это сработало бы, если бы Person был классом. Мы подробнее поговорим о различиях между типами значений и ссылочными типами в главе о Структурах и Классах. Тем не менее, это все еще слишком многословно. Вместо этого вы можете присвоить значение через цепочку опционала, и если оно не равно nil, присваивание будет выполнено:

optionalLisa?.age += 1

Странный (но логичный) крайний случай этой функции заключается в том, что она работает для прямого присваивания опциональным значениям. Это совершенно допустимо:

var a: Int? = 5
a? = 10
a // Optional(10)

var b: Int? = nil
b? = 10
b // nil

Обратите внимание на тонкое различие между a = 10 и a? = 10. Первое присваивает новое значение без условий, в то время как второе выполняет присваивание только в том случае, если значение a не равно nil перед присваиванием.

Оператор объединения с nil (Nil-Coalescing Operator) Link to heading

Часто вам нужно развернуть опциональное значение и заменить nil на какое-то значение по умолчанию. Это задача для оператора объединения с nil:

let stringteger = "1"
let number = Int(stringteger) ?? 0

Если строку можно преобразовать в целое число, number будет этим целым числом, развернутым. Если это невозможно и Int.init возвращает nil, будет подставлено значение по умолчанию 0. Таким образом, lhs ?? rhs аналогично lhs != nil ? lhs : rhs.

Если вы переходите на Swift с другого языка, вы можете подумать, что оператор объединения с nil похож на тернарный оператор (a ? b : c). Например, чтобы получить первый элемент из массива, который может быть пустым, вы могли бы написать следующий код:

let array = [1, 2, 3]
!array.isEmpty ? array[0] : 0

Поскольку массивы Swift предоставляют свойство first, которое равно nil, если массив пуст, вы можете использовать оператор объединения с nil вместо этого:

array.first ?? 0 // 1

Это более чисто и понятно — намерение (взять первый элемент массива) очевидно, с значением по умолчанию, добавленным в конце, соединенным с ??, который сигнализирует: “это значение по умолчанию”. Сравните это с версией с тернарным оператором, которая начинается с проверки, затем следует значение и заканчивается значением по умолчанию. И проверка неуклюже отрицательная (альтернативой было бы поставить значение по умолчанию посередине, а фактическое значение в конце). И, как это бывает с опциональными значениями, невозможно забыть, что first является опциональным, и случайно использовать его без проверки, потому что компилятор остановит вас, если вы попытаетесь.

Когда бы вы ни обнаружили, что защищаете оператор с помощью проверки, чтобы убедиться, что оператор действителен, это хороший знак, что опционалы будут лучшим решением. Предположим, что вместо пустого массива вы проверяете значение, которое находится в пределах массива:

array.count > 5 ? array[5] : 0 // 0

В отличие от first и last, получение элемента из массива по индексу не возвращает опциональное значение. Но легко расширить Array, чтобы добавить эту функциональность:

extension Array {
    subscript(guarded idx: Int) -> Element? {
        guard (startIndex..<endIndex).contains(idx) else {
            return nil
        }
        return self[idx]
    }
}

Теперь вы можете написать следующее:

array[guarded: 5] ?? 0 // 0

Объединение также может быть цепочечным — если у вас есть несколько возможных опционалов и вы хотите выбрать первое ненулевое значение, вы можете записать их в последовательности:

let i: Int? = nil
let j: Int? = nil
let k: Int? = 42
i ?? j ?? k ?? 0 // 42

Из-за этой цепочки, если вам когда-либо представят двойное вложенное опциональное значение и вы захотите использовать оператор ??, вы должны быть осторожны, чтобы различать a ?? b ?? c (цепочка) и (a ?? b) ?? c (разворачивание внутренних, а затем внешних слоев):

let s1: String?? = nil
(s1 ?? "inner") ?? "outer" // inner
let s2: String?? = .some(nil)
(s2 ?? "inner") ?? "outer" // outer

Если вы думаете об операторе ?? как о чем-то, аналогичном оператору “или”, вы можете рассматривать if let с несколькими условиями как оператор “и”:

if let n = i, let m = j { }
// аналогично if i != nil && j != nil

Как и оператор ||, оператор ?? использует короткое замыкание: когда мы пишем l ?? r, правая сторона оператора вычисляется только тогда, когда левая сторона равна nil. Это работает, потому что объявление функции для оператора использует @autoclosure для своего второго параметра. Мы обсудим, как работают автозамыкания, в главе о функциях.

Использование опционалов с интерполяцией строк Link to heading

Вы могли заметить, что компилятор выдает предупреждение, когда вы печатаете опциональное значение или используете его в выражении интерполяции строк:

let bodyTemperature: Double? = 37.0
let bloodGlucose: Double? = nil
print(bodyTemperature) // Optional(37.0)
// Warning: Expression implicitly coerced from 'Double?' to Any.
print("Уровень глюкозы в крови: \(bloodGlucose)") // Уровень глюкозы в крови: nil
// Warning: String interpolation produces a debug description
// for an optional value; did you mean to make this explicit?

Это обычно полезно, потому что слишком легко случайно вставить “Optional(…)” или “nil” в текст, отображаемый пользователю. Вы никогда не должны использовать опционалы напрямую в строках, предназначенных для пользователя, и всегда сначала распаковывать их. Поскольку все типы допускаются в интерполяции строк (включая Optional), компилятор не может сделать это жесткой ошибкой, поэтому предупреждение — это действительно лучшее, что он может сделать.

Иногда вы можете захотеть использовать опционал в интерполяции строк — например, для логирования его значения для отладки — и в этом случае предупреждения могут стать раздражающими. Компилятор предлагает несколько способов устранить предупреждение: добавить явное приведение типа с помощью as Any, принудительно распаковать значение с помощью ! (если вы уверены, что оно не может быть nil), обернуть его в String(describing:) или предоставить значение по умолчанию с помощью оператора объединения с nil.

Последний вариант часто является быстрым и довольно удобным решением, но у него есть один недостаток: типы с обеих сторон выражения ?? должны совпадать, поэтому значение по умолчанию, которое вы предоставляете для Double?, должно быть типа Double. Поскольку конечная цель — превратить выражение в строку, было бы удобно, если бы вы могли предоставить строку в качестве значения по умолчанию с самого начала.

Оператор ?? в Swift не поддерживает такого рода несоответствие типов — в конце концов, каков был бы тип выражения, если бы у двух сторон не было общего базового типа? Но легко добавить свой собственный оператор, который специально предназначен для работы с опционалами в интерполяции строк. Назовем его ???:

infix operator ???: NilCoalescingPrecedence

public func ???<T>(optional: T?, defaultValue: @autoclosure () -> String) -> String {
    switch optional {
    case let value?: return String(describing: value)
    case nil: return defaultValue()
    }
}

Это принимает любой опционал T? с левой стороны и строку с правой. Если опционал не равен nil, мы распаковываем его и возвращаем его строковое описание. В противном случае мы возвращаем строку по умолчанию, которая была передана. Аннотация @autoclosure гарантирует, что мы будем оценивать второй операнд только при необходимости. В главе о функциях мы рассмотрим это более подробно.

Теперь мы можем написать следующее, и мы не получим никаких предупреждений компилятора:

print("Температура тела: \(bodyTemperature ??? "н/д")")
// Температура тела: 37.0
print("Уровень глюкозы в крови: \(bloodGlucose ??? "н/д")")
// Уровень глюкозы в крови: н/д

Optional map Link to heading

Предположим, у нас есть массив символов, и мы хотим превратить первый элемент в строку:

let characters: [Character] = ["a", "b", "c"]
String(characters[0]) // a  

Если массив characters может быть пустым, мы можем использовать конструкцию if let, чтобы создать строку только в том случае, если массив не пуст:

var firstCharAsString: String? = nil
if let char = characters.first {  
    firstCharAsString = String(char)  
}  

Теперь, если массив содержит хотя бы один элемент, firstCharAsString будет содержать этот элемент в виде строки. Но если он пуст, firstCharAsString будет равен nil.
Этот шаблон — взять опционал и преобразовать его, если он не равен nil — достаточно распространен, чтобы для этого был метод на опционалах. Он называется map и принимает функцию, которая описывает, как преобразовать содержимое опционала. Вот вышеуказанная функция, переписанная с использованием map:

let firstChar = characters.first.map { String($0) } // Optional("a")  

Этот map, конечно, очень похож на map для массивов или других последовательностей. Но вместо того, чтобы работать с последовательностью значений, он работает только с одним значением: возможным значением внутри опционала. Вы можете рассматривать опционал как коллекцию из нуля или одного значения, при этом map либо ничего не делает с нулевыми значениями, либо преобразует одно.
Вот один из способов реализовать map для опционалов:

extension Optional {  
    func map<U>(transform: (Wrapped) -> U) -> U? {  
        guard let value = self else { return nil }  
        return transform(value)  
    }  
}  

Опциональный map особенно удобен, когда вы уже хотите получить опциональный результат. Предположим, вы хотите написать еще одну вариацию reduce для массивов. Вместо того, чтобы принимать начальное значение, она использует первый элемент в массиве (в некоторых языках это может называться reduce1, но мы назовем это reduce и полагаемся на перегрузку).
Из-за возможности того, что массив может быть пустым, результат должен быть опциональным — без начального значения, что еще это может быть? Вы можете написать это так:

extension Array {  
    func reduce( _ nextPartialResult: (Element, Element) -> Element) -> Element? {  
        // first будет nil, если массив пуст.  
        guard let fst = first else { return nil }  
        return dropFirst().reduce(fst, nextPartialResult)  
    }  
}  

И вы можете использовать это так:

[1, 2, 3, 4].reduce(+) // Optional(10)  

Поскольку опциональный map возвращает nil, если опционал равен nil, наша вариация reduce может быть переписана с использованием одного оператора return (и без guard):

extension Array {  
    func reduce_alt( _ nextPartialResult: (Element, Element) -> Element) -> Element? {  
        first.map {  
            dropFirst().reduce($0, nextPartialResult)  
        }  
    }  
}  

Optional.flatMap Link to heading

Как мы видели в главе о встроенных коллекциях, часто возникает необходимость применить функцию к коллекции, которая возвращает коллекцию, но собрать результаты в одном массиве, а не в массиве массивов. Аналогично, если вы хотите выполнить map над опциональным значением, но ваша функция преобразования также возвращает опциональный результат, вы получите дважды вложенный опционал. Примером этого является ситуация, когда вы хотите получить первый элемент массива строк в виде числа, используя first на массиве, а затем map, чтобы преобразовать его в число:

let stringNumbers = ["1", "2", "3", "foo"]
let x = stringNumbers.first.map { Int($0) } // Optional(Optional(1))

Проблема в том, что поскольку map возвращает опционал (возможно, first был равен nil), а Int(someString) также возвращает опционал (строка может не быть целым числом), тип x будет Int??.

flatMap вместо этого сгладит результат в один опционал. В результате y будет иметь тип Int?:

let y = stringNumbers.first.flatMap { Int($0) } // Optional(1)

Вместо этого вы могли бы написать это с помощью if let, потому что значения, которые будут связаны позже, могут быть вычислены из более ранних:

if let a = stringNumbers.first, let b = Int(a) {
    print(b)
} // 1

Это показывает, что flatMap и if let очень похожи. Ранее в этой главе мы видели пример, который использует множественное выражение if let, и мы можем переписать его, используя map и flatMap вместо этого:

let urlString = "https://www.objc.io/logo.png"
let view = URL(string: urlString)
    .flatMap { try? Data(contentsOf: $0) }
    .flatMap { UIImage(data: $0) }
    .map { UIImageView(image: $0) }

if let view = view {
    PlaygroundPage.current.liveView = view
}

Опциональная цепочка также аналогична flatMap: i?.advance(by: 1) по сути эквивалентно i.flatMap { $0.advance(by: 1) }.

Поскольку мы показали, что множественное выражение if let эквивалентно flatMap, мы могли бы реализовать одно через другое:

extension Optional {
    func flatMap<U>(transform: (Wrapped) -> U?) -> U? {
        if let value = self, let transformed = transform(value) {
            return transformed
        }
        return nil
    }
}

Фильтрация nil с помощью compactMap Link to heading

Если у вас есть последовательность, и она содержит опциональные значения, вы можете не обращать внимания на значения nil. На самом деле, вы можете просто захотеть игнорировать их. Предположим, вы хотите обработать только числа в массиве строк. Это легко сделать в цикле for, используя сопоставление с образцом для опционалов:

let numbers = ["1", "2", "3", "foo"]
var sum = 0
for case let i? in numbers.map({ Int($0) }) {
    sum += i
}
sum // 6

Вы также можете использовать оператор ??, чтобы заменить значения nil на нули:

numbers.map { Int($0) }.reduce(0) { $0 + ($1 ?? 0) } // 6

Но на самом деле вы просто хотите версию map, которая фильтрует nil и распаковывает ненулевые значения. Введите compactMap из стандартной библиотеки, который делает именно это:

numbers.compactMap { Int($0) }.reduce(0, +) // 6

Чтобы определить свою собственную версию compactMap, мы сначала применяем map ко всему массиву, затем фильтруем ненулевые значения и, наконец, распаковываем каждый элемент:

extension Sequence {
    func compactMap<B>(_ transform: (Element) -> B?) -> [B] {
        return lazy.map(transform).filter { $0 != nil }.map { $0! }
    }
}

В реализации мы используем lazy, чтобы отложить создание массива до последнего момента. Это, возможно, микрооптимизация, но она может быть полезной для больших последовательностей. Использование lazy экономит выделение нескольких промежуточных массивов. Однако стандартная библиотека не делает этого в своей реализации compactMap. В главе о протоколах коллекций мы рассмотрим ленивые последовательности и коллекции более подробно.

Equating Optionals Link to heading

Часто вам не важно, является ли значение nil или нет — важно только, содержит ли оно определенное значение:

let regex = "^Hello$"
    // ...
if regex.first == "^" {
    // Совпадение только с началом строки.
}

В этом случае не имеет значения, является ли значение nil или нет — если строка пуста, первый символ не может быть кареткой, поэтому вы не хотите выполнять этот блок. Но вы все равно хотите защиту и простоту от first. Альтернатива, если

!regex.isEmpty && regex[regex.startIndex] == "^",

ужасна.

Код выше зависит от двух вещей, чтобы работать. Во-первых, Optional соответствует Equatable, но только если его обернутый тип также соответствует Equatable:

extension Optional: Equatable where Wrapped: Equatable {
    static func** ==(lhs: Wrapped?, rhs: Wrapped?) -> Bool {
        switch (lhs, rhs) {
            case ( nil , nil ): return true
            case let (x?, y?): return x == y
            case ( _ ?, nil ), ( nil , _ ?): return false
        }
    }
}

При сравнении двух опционалов есть четыре возможности: они оба nil, или у них обоих есть значение, или одно из них nil. Switch исчерпывающе проверяет все четыре возможности (поэтому нет необходимости в условии по умолчанию). Он определяет, что два nil равны друг другу, nil никогда не равен ненулевому значению, и два ненулевых значения равны, если их развернутые значения равны.

Во-вторых, обратите внимание, что нам не нужно было писать следующее:

if regex.first == Optional("^") { // или: == .some("^")
    // Совпадение только с началом строки.
}

Это потому, что всякий раз, когда у вас есть ненулевое значение, Swift всегда будет готов преобразовать его в опциональное значение, чтобы типы совпадали.

Это неявное преобразование невероятно полезно для написания ясного и компактного кода. Предположим, что такого преобразования не было, но чтобы сделать все красиво для вызывающего, вам нужна версия ==, которая работала бы между опциональными и ненулевыми типами. Вам пришлось бы написать три отдельные версии:

// Оба опциональные.
func == <T: Equatable>(lhs: T?, rhs: T?) -> Bool
// lhs ненулевое.
func == <T: Equatable>(lhs: T, rhs: T?) -> Bool
// rhs ненулевое.
func == <T: Equatable>(lhs: T?, rhs: T) -> Bool

Но вместо этого нужна только первая версия, и компилятор преобразует в опционалы, где это необходимо.

На самом деле, мы полагались на эту функцию на протяжении всей книги. Например, когда мы реализовали Optional.map, мы преобразовали внутреннее значение и вернули его. Но возвращаемое значение map — это Optional. Компилятор автоматически преобразовал значение для нас — нам не нужно было писать

return Optional(transform(value)).

Код Swift постоянно полагается на это неявное преобразование. Например, поиск по ключу в словаре возвращает опциональное значение (ключ может отсутствовать). Но он также принимает опциональное значение при присвоении — подпрограммы должны как принимать, так и возвращать один и тот же тип. Без неявного преобразования вам пришлось бы писать

myDict["someKey"] = Optional(someValue).

Кстати, если вы задаетесь вопросом, что происходит со словарями с присвоением по ключу, когда вы присваиваете значение nil, ответ заключается в том, что ключ удаляется. Это может быть полезно, но также означает, что вам нужно быть немного осторожным при работе со словарем с опциональным типом значения. Рассмотрим этот словарь:

var dictWithNils: [String: Int?] = [
"one": 1,
"two": 2,
"none": nil
]

Словарь имеет три ключа, и один из них имеет значение nil. Предположим, мы хотели бы установить значение ключа “two” в nil также. Это не сработает:

dictWithNils["two"] = nil
dictWithNils // ["one": Optional(1), "none": nil]

Вместо этого он удалит ключ “two”.

Чтобы изменить значение для ключа, вам нужно будет написать одно из следующих (все они работают, так что выберите то, что вам кажется более ясным):

dictWithNils["two"] = Optional( nil )
dictWithNils["two"] = .some( nil )
dictWithNils["two"]? = nil
dictWithNils // ["one": Optional(1), "two": nil, "none": nil]

Обратите внимание, что третья версия выше немного отличается от других двух. Она работает, потому что ключ “two” уже есть в словаре, поэтому используется опциональная цепочка для установки его значения, если оно успешно получено. Теперь попробуйте это с ключом, который отсутствует:

dictWithNils["three"]? = nil
dictWithNils.index(forKey: "three") // nil

Вы можете видеть, что ничего не будет обновлено/вставлено.

Сравнение опционалов Link to heading

Подобно оператору ==, ранее существовали реализации операторов <, >, <= и >= для опционалов. В Swift 3.0 эти операторы сравнения были удалены для опционалов, поскольку они могут легко приводить к неожиданным результатам.

Например, nil < .some(_) вернет true. В сочетании с функциями высшего порядка или цепочками опционалов это может быть очень неожиданно. Рассмотрим следующий (устаревший) пример:

let temps = ["-459.67", "98.6", "0", "warm"]  
let belowFreezing = temps.filter { Double($0) < 0 }

Поскольку Double(“warm”) вернет nil, а nil был определен как меньше 0, он был бы включен в температуры ниже нуля. Это действительно неожиданно.

Если вам нужны отношения неравенства между опционалами, теперь вам нужно сначала развернуть значения и тем самым явно решить, как следует обрабатывать nil значения.

Когда использовать принудительное извлечение Link to heading

Учитывая все эти техники аккуратного извлечения опционалов, когда следует использовать !, оператор принудительного извлечения? В интернете можно встретить множество мнений на этот счет, включая «никогда», «когда это делает код более понятным» и «когда вы не можете этого избежать». Мы предлагаем следующее правило, которое охватывает большинство из них:

Используйте !, когда вы настолько уверены, что значение не будет nil, что хотите, чтобы ваша программа завершилась с ошибкой, если это когда-либо произойдет.

В качестве примера возьмем реализацию compactMap из вышеуказанного текста:

extension Sequence {
    func compactMap<B>(_ transform: (Element) -> B?) -> [B] {
        return lazy.map(transform).filter { $0 != nil }.map { $0! }
    }
}

Здесь нет никакой возможности, что $0! внутри map когда-либо вернет nil, так как все nil элементы были отфильтрованы на предыдущем шаге. Эта функция, безусловно, могла бы быть написана так, чтобы исключить оператор принудительного извлечения, перебирая массив и добавляя ненулевые значения в новый массив. Но версия с filter/map более чистая и, вероятно, более понятная, поэтому использование ! оправдано.

Тем не менее, такие случаи довольно редки. Если вы полностью овладели всеми техниками извлечения, описанными в этой главе, скорее всего, есть лучший способ, чем принудительное извлечение. Каждый раз, когда вы тянетесь за !, стоит сделать шаг назад и задуматься, действительно ли нет другого варианта.

В качестве другого примера рассмотрим следующий код, который извлекает все ключи из словаря с значениями, соответствующими определенному условию:

let ages = [
    "Tim": 53, "Angela": 54, "Craig": 44,
    "Jony": 47, "Chris": 37, "Michael": 34,
]
ages.keys
    .filter { name in ages[name]! < 50 }
    .sorted()
// ["Chris", "Craig", "Jony", "Michael"]

Снова ! здесь абсолютно безопасен — поскольку все ключи пришли из словаря, нет никакой возможности, что ключ может отсутствовать в словаре.

Но вы также можете переписать это выражение, чтобы полностью исключить необходимость в принудительном извлечении. Используя тот факт, что словари представляют собой последовательности пар ключ-значение, вы можете просто отфильтровать эту последовательность, а затем применить map, чтобы удалить значение:

ages.filter { (_, age) in age < 50 }
    .map { (name, _) in name }
    .sorted()
// ["Chris", "Craig", "Jony", "Michael"]

Эта версия даже может иметь потенциальную выгоду по производительности, так как избегает ненужных обращений к ключам.

Тем не менее, иногда жизнь подбрасывает вам опционал, и вы точно знаете, что он не равен nil. Вы настолько уверены в этом, что предпочли бы, чтобы ваша программа завершилась с ошибкой, чем продолжала работу, потому что столкновение с nil значением означало бы наличие очень неприятной ошибки в вашей логике. Лучше поймать ошибку, чем продолжать в таких обстоятельствах, поэтому ! действует как комбинированный оператор извлечения или ошибки в одном удобном символе. Этот подход часто является более разумным решением, чем просто использование операторов цепочки nil или объединения, чтобы замести теоретически невозможные ситуации под ковер.

Улучшение Force-UnwrapErrorMessages Link to heading

Тем не менее, даже когда вы принудительно извлекаете значение из опционала, у вас есть варианты, помимо использования оператора !. Когда ваша программа выдает ошибку, вы не получаете много информации о том, почему, в журнале вывода.

Скорее всего, вы оставите комментарий о том, почему вы оправданы в принудительном извлечении. Так почему бы не сделать так, чтобы этот комментарий также служил сообщением об ошибке? Вот оператор, !!; он сочетает извлечение с предоставлением более описательного сообщения об ошибке, которое будет записано в журнал при выходе приложения:

infix operator !!

func !! <T>(wrapped: T?, failureText: @autoclosure () -> String) -> T {
    if let x = wrapped { return x }
    fatalError(failureText())
}

Теперь вы можете написать более описательное сообщение об ошибке, включая значение, которое вы ожидали, чтобы можно было извлечь:

let s = "foo"
let i = Int(s) !! "Ожидалось целое число, получено \"\(s)\""

Утверждения в отладочных сборках Link to heading

Тем не менее, выбор возможности аварийного завершения даже в релизных сборках — довольно смелый шаг. Часто вы можете предпочесть использовать утверждения во время отладки и тестирования, но в производственной среде вы бы заменили их на допустимое значение по умолчанию — возможно, на ноль или пустой массив.

Вводим оператор интерробанг, !?. Мы определяем этот оператор для утверждения при неудачных распаковках, а также для замены значения по умолчанию, когда утверждение не срабатывает в режиме релиза:

infix operator !?
func !?<T: ExpressibleByIntegerLiteral>(wrapped: T?, failureText: @autoclosure () -> String) -> T {
    assert(wrapped != nil, failureText())
    return wrapped ?? 0
}

Теперь следующее утверждение будет работать во время отладки, но вернет 0 в релизе:

let s = "20"
let i = Int(s) !? "Ожидалось целое число, получено \"\(s)\""

Перегрузка для других протоколов, поддерживающих литералы, позволяет охватить широкий спектр типов, которые могут иметь значение по умолчанию:

func !?<T: ExpressibleByArrayLiteral>(wrapped: T?, failureText: @autoclosure () -> String) -> T {
    assert(wrapped != nil, failureText())
    return wrapped ?? []
}

func !?<T: ExpressibleByStringLiteral>(wrapped: T?, failureText: @autoclosure () -> String) -> T {
    assert(wrapped != nil, failureText())
    return wrapped ?? ""
}

А для случаев, когда вы хотите предоставить другое явное значение по умолчанию или для нестандартных типов, вы можете определить версию, которая принимает пару — значение по умолчанию и текст ошибки:

func !?<T>(wrapped: T?, nilDefault: @autoclosure () -> (value: T, text: String)) -> T {
    assert(wrapped != nil, nilDefault().text)
    return wrapped ?? nilDefault().value
}

// Утверждает в отладке, возвращает 5 в релизе.

Int(s) !? (5, "Ожидалось целое число")

Поскольку опционально цепочечные вызовы методов, возвращающих Void, возвращают Void?, вы также можете написать не обобщенную версию для обнаружения, когда опциональная цепочка достигает nil, что приводит к бездействию:

func !?(wrapped: ()?, failureText: @autoclosure () -> String) {
    assert(wrapped != nil, failureText())
}

var output: String? = nil
output?.write("что-то") !? "Не ожидал цепочку nil здесь"

Существует три способа остановить выполнение. Первый вариант, fatalError, принимает сообщение и останавливает выполнение без условий. Второй вариант, assert, проверяет условие и сообщение и останавливает выполнение, если условие оценивается как false. В релизных сборках assert удаляется — условие не проверяется (и выполнение никогда не останавливается). Третий вариант — precondition, который имеет тот же интерфейс, что и assert, но не удаляется из релизных сборок, поэтому, если условие оценивается как false, выполнение останавливается.

Неявно распакованные опционалы Link to heading

Не делайте ошибок: неявно распакованные опционалы — это типы, отмеченные восклицательным знаком, такие как UIView!, — это все еще опционалы, хотя и такие, которые автоматически распаковываются при каждом их использовании. Теперь, когда мы знаем, что принудительное распаковка приведет к сбою вашего приложения, если они когда-либо будут равны nil, зачем же их использовать? На самом деле, есть две причины.

Причина 1: Временно, потому что вы вызываете код на Objective-C, который не был проверен на наличие нулевых значений, или потому что вы обращаетесь к библиотеке C, которая не имеет аннотаций, специфичных для Swift.

Единственная причина, по которой неявно распакованные опционалы вообще существуют, — это упрощение взаимодействия с Objective-C и C. Конечно, в первый день, когда вы начинаете писать Swift против существующей кодовой базы на Objective-C, любой метод Objective-C, который возвращает ссылку, будет преобразован в неявно распакованный опционал. Поскольку на протяжении большей части времени существования Objective-C не было способа указать, что ссылка может быть нулевой, не оставалось другого выбора, кроме как предполагать, что любой вызов, возвращающий ссылку, может вернуть nil. Но немногие API Objective-C на самом деле возвращают нулевые ссылки, поэтому было бы невероятно неудобно автоматически представлять их как опционалы. Поскольку все привыкли иметь дело с миром объектов Objective-C, где “может быть нулевым”, неявно распакованные опционалы стали разумным компромиссом.

Таким образом, вы увидите их в неаудированном мостовом коде Objective-C. Но вы никогда не должны видеть чистый нативный API Swift, возвращающий неявный опционал (или передающий его в обратный вызов).

Причина 2: Потому что значение является nil очень короткое время, в четко определенный период времени, а затем никогда больше не становится nil.

Наиболее распространенный сценарий — это инициализация в два этапа. К тому времени, когда ваш класс готов к использованию, все неявно распакованные опционалы будут иметь значение. Именно поэтому Xcode/Interface Builder использует их в жизненном цикле контроллера представления: в Cocoa и Cocoa Touch контроллеры представления создают свои представления лениво, поэтому существует временное окно — после инициализации контроллера представления, но до загрузки его представления — когда объекты представления, на которые ссылается контроллер представления, еще не были созданы.

ImplicitOptionalBehavior Link to heading

Хотя неявно распакованные опционалы обычно ведут себя как значения, не являющиеся опциональными, вы все равно можете использовать большинство техник распаковки, чтобы безопасно обрабатывать их как опционалы — цепочки, объединение с nil, if let, map или просто сравнение с nil работают одинаково:

var s: String! = "Hello"  
s?.isEmpty // Optional(false)  
if let s = s { print(s) } // Hello  
s = nil  
s ?? "Goodbye" // Goodbye  

Резюме Link to heading

Опционалы считаются одной из самых больших особенностей Swift для написания более безопасного кода, и мы с этим определенно согласны. Однако, если задуматься, настоящим прорывом являются не опционалы, а не-опционалы. Почти каждый современный язык программирования имеет концепцию “null” или “nil”; то, чего большинству из них не хватает, так это возможности объявить значение как “никогда не nil”. Или, альтернативно, некоторые типы (например, не-классовые типы в Objective-C или Java) “всегда не nil”, заставляя разработчиков придумывать магические значения для представления отсутствия значения.

API, входные и выходные данные которых тщательно спроектированы с учетом опционалов, более выразительны и проще в использовании; меньше необходимости обращаться к документации, поскольку типы несут больше информации.

Все техники распаковки, которые мы продемонстрировали в этой главе, являются попыткой Swift сделать переход между двумя мирами опциональных и не-опциональных значений как можно менее болезненным. Какой метод использовать, часто является вопросом личных предпочтений.

Функции Link to heading

4 Link to heading

Обзор Link to heading

Перед тем как перейти к этой главе, давайте подведем итоги некоторых основных моментов, касающихся функций. Если вы уже знакомы с функциями первого класса, можете смело перейти к следующему разделу. Но если вы хоть немного не уверены в них, прочитайте то, что ниже.

Чтобы понять функции и замыкания в Swift, вам действительно нужно понять три вещи, примерно в следующем порядке важности:

0. Функции могут быть присвоены переменным и переданы в другие функции в качестве аргументов, так же как и Int или String.
1. Функции могут захватывать переменные, которые существуют вне их локальной области видимости.
2. Существует два способа создания функций — либо с помощью ключевого слова func, либо с помощью {}. Swift называет последнее выражениями замыкания.

Иногда люди, новички в теме замыканий, подходят к этому в обратном порядке и могут пропустить один из этих пунктов, или же они путают термины “замыкание” и “выражение замыкания” — и это может вызвать много путаницы. Это трехногий табурет, и если вы пропустите один из трех пунктов выше, вы упадете, когда попытаетесь на него сесть.

1. Функции могут быть присвоены переменным и передаваться внутрь и наружу Link to heading

Другие функции как аргументы. Link to heading

В Swift, как и во многих современных языках, функции рассматриваются как «объекты первого класса». Вы можете присваивать функции переменным, а также передавать их в другие функции для последующего вызова. Это самое важное, что нужно понять. Понять это для функционального программирования подобно тому, как понять указатели в C. Если вы не совсем усвоили эту часть, все остальное будет просто шумом.

Давайте начнем с функции, которая просто выводит целое число:

func printInt(i: Int) {
    print("Вы передали \(i).")
}

Чтобы присвоить функцию переменной funVar, мы используем имя функции в качестве значения. Обратите внимание на отсутствие скобок после имени функции:

let funVar = printInt

Теперь мы можем вызвать функцию printInt, используя переменную funVar. Обратите внимание на использование скобок после имени переменной:

funVar(2) // Вы передали 2.

Также стоит отметить, что мы не должны включать метку аргумента в вызов funVar, в то время как вызовы printInt требуют метку аргумента, как в printInt(i: 2). Swift позволяет использовать метки аргументов только в объявлениях функций; метки не включаются в тип функции. Это означает, что в настоящее время вы не можете присваивать метки аргументов переменной типа функции, хотя это, вероятно, изменится в будущих версиях Swift.

Мы также можем написать функцию, которая принимает функцию в качестве аргумента:

func useFunction(function: (Int) -> ()) {
    function(3)
}

useFunction(function: printInt) // Вы передали 3.
useFunction(function: funVar) // Вы передали 3.

Почему возможность обращаться с функциями таким образом так важна? Потому что это позволяет нам легко писать «функции высшего порядка», которые принимают функции в качестве аргументов и применяют их полезным образом, как мы видели в главе о встроенных коллекциях.

Функции также могут возвращать другие функции:

func returnFunc() -> (Int) -> String {
    func innerFunc(i: Int) -> String {
        return "Вы передали \(i)."
    }
    return innerFunc
}

let myFunc = returnFunc()
myFunc(3) // Вы передали 3.

2. Функции могут захватывать переменные, которые существуют вне их локальной области Link to heading

Область видимости. Link to heading

Когда функция ссылается на переменные вне своей области видимости, эти переменные захватываются и остаются доступными даже после того, как они в противном случае вышли бы из области видимости и были бы уничтожены. Чтобы это продемонстрировать, давайте снова рассмотрим нашу функцию returnFunc, но добавим счетчик, который увеличивается каждый раз, когда мы ее вызываем:

func makeCounter() -> (Int) -> String {
    var counter = 0
    func innerFunc(i: Int) -> String {
        counter += i // counter захватывается
        return "Текущая сумма: \(counter)"
    }
    return innerFunc
}

Обычно переменная counter, будучи локальной переменной makeCounter, вышла бы из области видимости сразу после оператора return, и она была бы уничтожена. Вместо этого, поскольку она захвачена innerFunc, среда выполнения Swift будет поддерживать ее в живых до тех пор, пока функция, которая ее захватила, не будет уничтожена. Мы можем вызывать внутреннюю функцию несколько раз, и мы увидим, что текущая сумма увеличивается:

let f = makeCounter()
f(3) // Текущая сумма: 3
f(4) // Текущая сумма: 7

Если мы снова вызовем makeCounter(), будет создана новая переменная counter, которая будет захвачена:

let g = makeCounter()
g(2) // Текущая сумма: 2
g(2) // Текущая сумма: 4

Это не влияет на нашу первую функцию, которая все еще имеет свою собственную захваченную версию counter:

f(2) // Текущая сумма: 9

Думайте об этих функциях в сочетании с их захваченными переменными как о чем-то подобном экземплярам классов с одним методом (функцией) и некоторыми переменными-членами (захваченными переменными). В терминологии программирования комбинация функции и окружения захваченных переменных называется замыканием. Таким образом, f и g выше являются примерами замыканий, потому что они захватывают и используют не локальную переменную (counter), которая была объявлена вне их.

3. Функции могут быть объявлены с использованием синтаксиса {} для замыкания Link to heading

Выражения. Link to heading

В Swift вы можете определять функции двумя способами. Один из них — с помощью ключевого слова func. Другой способ — использовать выражение замыкания. Рассмотрим эту простую функцию для удвоения числа:

func doubler(i: Int) -> Int {
    return i * 2
}

[1, 2, 3, 4].map(doubler) // [2, 4, 6, 8]

А вот та же функция, написанная с использованием синтаксиса выражения замыкания. Как и раньше, мы можем передать ее в map:

let doublerAlt = { (i: Int) -> Int in return i * 2 }

[1, 2, 3, 4].map(doublerAlt) // [2, 4, 6, 8]

Функции, объявленные как выражения замыкания, можно рассматривать как литералы функций так же, как 1 и “hello” являются литералами для целых чисел и строк. Они также анонимны — у них нет имени, в отличие от функций, объявленных с помощью ключевого слова func. Единственный способ их использования — это присвоение их переменной при создании (как мы делаем здесь с doubler), или передача их в другую функцию или метод.

Существует третий способ использования анонимных функций: вы можете вызывать функцию непосредственно в строке, которая определяет ее. Это может быть полезно для определения свойств, инициализация которых требует больше одной строки. Мы увидим пример этого в главе о свойствах.

Замыкание, объявленное с использованием выражения замыкания, и то, что было объявлено ранее с помощью ключевого слова func, полностью эквивалентны, за исключением различий в их обработке меток аргументов, о которых мы упоминали выше. Они даже существуют в одном и том же “пространстве имен”, в отличие от некоторых языков.

Почему же синтаксис {} полезен? Почему бы не использовать func каждый раз? Ну, это может быть гораздо более компактно, особенно при написании быстрых функций для передачи в другие функции, такие как map. Вот наш пример с map для удвоения, написанный в гораздо более короткой форме:

[1, 2, 3].map { $0 * 2 } // [2, 4, 6]

Это выглядит очень по-другому, потому что мы использовали несколько возможностей Swift, чтобы сделать код более лаконичным. Вот они, по одному:

0. Если вы передаете замыкание в качестве аргумента и это все, что вам нужно, нет необходимости сначала сохранять его в локальной переменной. Подумайте об этом как о передаче числового выражения, такого как 5 * i, в функцию, которая принимает Int в качестве параметра.
1. Если компилятор может вывести тип из контекста, вам не нужно его указывать. В нашем примере функция, переданная в map, принимает Int (выведенный из типа элементов массива) и возвращает Int (выведенный из типа выражения умножения).
2. Если тело выражения замыкания содержит только одно выражение, оно автоматически вернет значение этого выражения, и вы можете опустить return.
3. Swift автоматически предоставляет короткие имена для аргументов функции — $0 для первого, $1 для второго и т.д.
4. Если последний аргумент функции — это выражение замыкания, вы можете вынести выражение за скобки вызова функции. Этот синтаксис “замыкания на конце” удобен, если у вас есть многострочное выражение замыкания, так как оно больше похоже на обычное определение функции или другой блочный оператор, такой как if expr {}. Начиная с Swift 5.3, поддерживаются даже несколько замыканий на конце.
5. Наконец, если функция не имеет аргументов, кроме выражения замыкания, вы можете полностью опустить скобки после имени функции.

Используя каждое из этих правил, мы можем свести выражение ниже к форме, показанной выше:

/*_*/ [1, 2, 3].map( { (i: Int) -> Int in return i * 2 } )
/*_*/ [1, 2, 3].map( { i in return i * 2 } )
/*_*/ [1, 2, 3].map( { i in i * 2 } )
/*_*/ [1, 2, 3].map( { $0 * 2 } )
/*_*/ [1, 2, 3].map() { $0 * 2 }
/*_*/ [1, 2, 3].map { $0 * 2 }

Если вы новичок в синтаксисе Swift и функциональном программировании в целом, эти компактные объявления функций могут показаться пугающими в начале. Но по мере того, как вы будете более уверенно чувствовать себя с синтаксисом и стилем функционального программирования, они начнут казаться более естественными, и вы оцените возможность убрать лишние детали, чтобы яснее видеть, что делает код. Как только вы привыкнете читать код, написанный таким образом, его будет даже легче воспринимать на глаз, чем эквивалентный код, написанный с использованием обычного цикла for.

Иногда Swift нуждается в помощи с выводом типов. И иногда вы можете сделать что-то неправильно, и типы не будут такими, какими вы думаете, что они должны быть. Если вы когда-либо получите загадочную ошибку при попытке предоставить выражение замыкания, хорошей идеей будет записать полную форму (первую версию выше), с указанием типов. Во многих случаях это поможет прояснить, где происходит ошибка. Как только у вас будет компилируемая длинная форма, убирайте типы один за другим, пока компилятор не начнет жаловаться. И если ошибка была вашей, вы исправите свой код в процессе.

Swift также будет настаивать на том, чтобы вы были более явными иногда. Например, вы не можете полностью игнорировать входные параметры. Предположим, вы хотите массив случайных чисел. Быстрый способ сделать это — замапировать диапазон с функцией, которая просто генерирует случайные числа. Тем не менее, вы должны предоставить аргумент. Вы можете использовать _ в таких случаях, чтобы указать компилятору, что вы признаете, что есть аргумент, но вам не важно, что это:

(0..<3).map { _ in Int.random(in: 1..<100) } // [26, 57, 48]

Когда вам нужно явно указать типы переменных, вам не нужно делать это внутри выражения замыкания. Например, попробуйте определить isEven без указания типов:

let isEven = { $0 % 2 == 0 }

В приведенном выше примере тип isEven выводится как (Int) -> Bool так же, как let i = 1 выводится как Int — потому что Int является типом по умолчанию для целочисленных литералов.

Это связано с типом-алиасом IntegerLiteralType в стандартной библиотеке:

protocol ExpressibleByIntegerLiteral {
    associatedtype IntegerLiteralType
    /// Создать экземпляр, инициализированный значением `value`.
    init(integerLiteral value: IntegerLiteralType)
}

/// Тип по умолчанию для иначе неконтролируемого целочисленного литерала.
typealias IntegerLiteralType = Int

Если бы вы определили свой собственный тип-алиас, он бы переопределил тип по умолчанию и изменил это поведение:

typealias IntegerLiteralType = UInt32
let i = 1 // i будет типа UInt32.

Это, вероятно, плохая идея.

Если, однако, вам нужна версия isEven для другого типа, вы могли бы указать аргумент и возвращаемое значение внутри выражения замыкания:

let isEvenAlt = { (i: Int8) -> Bool in i % 2 == 0 }

Но вы также можете предоставить контекст извне замыкания:

let isEvenAlt2: (Int8) -> Bool = { $0 % 2 == 0 }
let isEvenAlt3 = { $0 % 2 == 0 } as (Int8) -> Bool

Поскольку выражения замыкания чаще всего используются в контексте существующих входных или выходных типов, добавление явного типа не так часто необходимо, но полезно знать, что вы можете это сделать.

Конечно, было бы гораздо лучше определить обобщенную версию isEven, которая работает с любым целым числом как вычисляемое свойство:

extension BinaryInteger {
    var isEven: Bool { return self % 2 == 0 }
}

В качестве альтернативы, мы могли бы выбрать определение варианта isEven для всех типов Integer как свободной функции:

func isEven<T: BinaryInteger>(_ i: T) -> Bool {
    return i % 2 == 0
}

Если вы хотите присвоить эту свободную функцию переменной, это также тот случай, когда вам нужно будет зафиксировать, с какими конкретными типами она работает. Переменная не может хранить обобщенную функцию — только конкретную:

let int8IsEven: (Int8) -> Bool = isEven

Последний момент о наименовании. Важно помнить, что функции, объявленные с помощью func, могут быть замыканиями, так же как и те, которые объявлены с помощью {}. Помните, что замыкание — это функция, объединенная с любыми захваченными переменными. Хотя функции, созданные с помощью {}, называются выражениями замыкания, люди часто называют этот синтаксис просто замыканиями. Но не путайте и не думайте, что функции, объявленные с помощью синтаксиса выражения замыкания, отличаются от других функций — это не так. Все они являются функциями, и все они могут быть замыканиями.

Гибкость через функции Link to heading

В главе о встроенных коллекциях мы говорили о параметризации поведения, передавая функции в качестве аргументов. Давайте рассмотрим еще один пример этого: сортировку.

Сортировка коллекции в Swift проста:

let myArray = [3, 1, 2]
myArray.sorted() // [1, 2, 3]

Существует четыре метода сортировки: немутирующий вариант sorted(by:), и мутирующий sort(by:), два из которых по умолчанию сортируют сопоставимые элементы в порядке возрастания и не принимают аргументов. В самом распространенном случае sorted() — это все, что вам нужно. А если вы хотите отсортировать в другом порядке, просто передайте функцию:

myArray.sorted(by: >) // [3, 2, 1]

Вы также можете передать функцию, если ваши элементы не соответствуют Comparable, но имеют оператор <, как это делают кортежи:

var numberStrings = [(2, "two"), (1, "one"), (3, "three")]
numberStrings.sort(by: <)
numberStrings // [(1, "one"), (2, "two"), (3, "three")]

(Предложение автоматически сделать кортежи совместимыми со стандартными протоколами, такими как Comparable, SE-0283, было принято в 2020 году, но еще не реализовано на момент Swift 5.5.)

Или вы можете предоставить более сложную функцию, если хотите отсортировать по каким-то произвольным критериям:

let animals = ["elephant", "zebra", "dog"]
animals.sorted { lhs, rhs in
    let l = lhs.reversed()
    let r = rhs.reversed()
    return l.lexicographicallyPrecedes(r)
}
// ["zebra", "dog", "elephant"]

Именно эта последняя возможность — возможность использовать любую функцию сравнения для сортировки коллекции — делает сортировку в Swift такой мощной.

Однако что, если мы захотим сортировать по нескольким критериям? Например, рассмотрим структуру Person, которую мы хотим отсортировать по фамилии, а затем по имени, если фамилии равны. В Objective-C это делалось с помощью NSSortDescriptor. Хотя NSSortDescriptor (и его современный вариант, SortDescriptor) гибок и мощен, он работает только с NSObject. Это ограничение существует, потому что он использует систему выполнения Objective-C. В этом разделе мы используем функции высшего порядка, чтобы реализовать свой собственный SortDescriptor, который будет столь же гибким и мощным.

Мы начинаем с определения типа Person:

struct Person {
    let first: String
    let last: String
    let yearOfBirth: Int
}

Давайте также определим массив людей с разными именами и годами рождения:

let people = [
    Person(first: "Emily", last: "Young", yearOfBirth: 2002),
    Person(first: "David", last: "Gray", yearOfBirth: 1991),
    Person(first: "Robert", last: "Barnes", yearOfBirth: 1985),
    Person(first: "Ava", last: "Barnes", yearOfBirth: 2000),
    Person(first: "Joanne", last: "Miller", yearOfBirth: 1994),
    Person(first: "Ava", last: "Barnes", yearOfBirth: 1998),
]

Мы хотим отсортировать этот массив сначала по фамилии, затем по имени, и наконец по году рождения. Порядок должен учитывать настройки локали пользователя. Сначала мы отсортируем только по одному ключу, фамилии:

people.sorted { p1, p2 in
    p1.last.localizedStandardCompare(p2.last) == .orderedAscending
}

Если мы хотим сравнить по фамилии, а затем по имени, это уже становится гораздо сложнее:

people.sorted { p1, p2 in
    switch p1.last.localizedStandardCompare(p2.last) {
    case .orderedAscending:
        return true
    case .orderedDescending:
        return false
    case .orderedSame:
        return p1.first.localizedStandardCompare(p2.first) == .orderedAscending
    }
}

Функции как данные Link to heading

Вместо того чтобы писать еще более сложную функцию, чтобы включить год рождения, мы можем сделать шаг назад и попытаться ввести абстракцию, которая описывает упорядочение значений. Методы стандартной библиотеки sort(by:) и sorted(by:) используют функцию сравнения, которая принимает два объекта и возвращает true, если они упорядочены правильно. Мы могли бы назвать это нашим дескриптором сортировки, определив обобщенный тип-алиас для него:

typealias SortDescriptor<Root> = (Root, Root) -> Bool

Другой альтернативой является определение обертки-структуры вокруг этой функции. Преимущество оборачивания функции в структуру заключается в том, что мы можем определить несколько инициализаторов и методов экземпляра и сделать их легкими для обнаружения через автозаполнение кода. Обернуть функцию в структуру или нет — это в основном вопрос личных предпочтений, но в этом случае это делает результирующий API более естественным для Swift:

struct SortDescriptor<Root> {
    var areInIncreasingOrder: (Root, Root) -> Bool
}

В качестве примера мы могли бы определить дескриптор сортировки, который сравнивает два значения Person по году рождения, или дескриптор сортировки, который сортирует по фамилии:

let sortByYear: SortDescriptor<Person> = .init { $0.yearOfBirth < $1.yearOfBirth }
let sortByLastName: SortDescriptor<Person> = .init {
    $0.last.localizedStandardCompare($1.last) == .orderedAscending
}

Вместо того чтобы писать дескрипторы сортировки вручную, мы можем написать функцию, которая их генерирует. Это не очень удобно, что нам нужно писать одно и то же свойство дважды: в sortByLastName мы могли бы легко допустить ошибку и случайно сравнить $0.last с $1.first. Кроме того, утомительно писать эти дескрипторы сортировки; чтобы отсортировать по имени, вероятно, проще всего скопировать и вставить определение sortByLastName и изменить его. Сначала давайте упростим создание дескриптора сортировки, который работает для любого свойства, которое является Comparable:

extension SortDescriptor {
    init <Value: Comparable>( _ key: @escaping (Root) -> Value) {
        self.areInIncreasingOrder = { key($0) < key($1) }
    }
}

Функция key описывает, как углубиться в элемент типа Root и извлечь значение типа Value, которое имеет отношение к одному конкретному шагу сортировки. Она имеет много общего с ключевыми путями Swift, и именно поэтому мы заимствовали наименования обобщенных параметров — Root и Value — из типа KeyPath. Позже в этой главе мы обсудим, как переписать дескрипторы сортировки, используя ключевые пути.

Теперь мы можем определить наш дескриптор sortByYear, используя новый инициализатор:

let sortByYearAlt: SortDescriptor<Person> = .init { $0.yearOfBirth }

Аналогично, мы можем создать инициализатор для случая, когда у нас есть функция с той же формой, что и localizedStandardCompare, и другие методы Foundation, которые возвращают ComparisonResult. Если мы сделаем часть String обобщенной, наш инициализатор будет выглядеть так:

extension SortDescriptor {
    init <Value>( _ key: @escaping (Root) -> Value,
                     by compare: @escaping (Value) -> (Value) -> ComparisonResult) {
        self.areInIncreasingOrder = {
            compare(key($0))(key($1)) == .orderedAscending
        }
    }
}

Если вы посмотрите на тип выражения String.localizedStandardCompare, вы заметите, что это (String) -> (String) -> ComparisonResult. Что здесь происходит? Внутри экземплярные методы моделируются как функции, которые, принимая экземпляр, возвращают другую функцию, которая затем работает с этим экземпляром. someString.localizedStandardCompare на самом деле просто другой способ записи String.localizedStandardCompare(someString) — оба выражения возвращают функцию типа (String) -> ComparisonResult, и эта функция является замыканием, которое захватило someString.

Это позволяет нам записать sortByFirstName очень лаконично:

let sortByFirstName: SortDescriptor<Person> =
    .init({ $0.first }, by: String.localizedStandardCompare)

Когда мы хотим сортировать по нескольким свойствам, мы можем объединить два дескриптора сортировки в один. Мы можем сначала сравнить, используя первичный дескриптор сортировки, и если значения не находятся ни в возрастающем, ни в убывающем порядке, мы используем результат второго дескриптора сортировки:

extension SortDescriptor {
    func then( _ other: SortDescriptor<Root>) -> SortDescriptor<Root> {
        SortDescriptor { x, y in
            if areInIncreasingOrder(x, y) { return true }
            if areInIncreasingOrder(y, x) { return false }
            return other.areInIncreasingOrder(x, y)
        }
    }
}

Это позволяет нам объединить все три наших дескриптора сортировки в один дескриптор сортировки, который их комбинирует:

let combined = sortByLastName.then(sortByFirstName).then(sortByYear)
people.sorted(by: combined.areInIncreasingOrder)
/*
[Person(first: "Ava", last: "Barnes", yearOfBirth: 1998),
 Person(first: "Ava", last: "Barnes", yearOfBirth: 2000),
 Person(first: "Robert", last: "Barnes", yearOfBirth: 1985),
 Person(first: "David", last: "Gray", yearOfBirth: 1991),
 Person(first: "Joanne", last: "Miller", yearOfBirth: 1994),
 Person(first: "Emily", last: "Young", yearOfBirth: 2002)]
*/

Хотя наше решение еще не так выразительно, как дескрипторы сортировки Foundation, оно работает со всеми значениями в Swift, а не только с NSObject. Кроме того, поскольку мы не полагаемся на программирование во время выполнения, компилятор может оптимизировать наш код гораздо лучше.

Одним из недостатков подхода на основе функций является то, что функции являются непрозрачными. Мы можем взять NSSortDescriptor и вывести его в консоль, и мы получим некоторую информацию о дескрипторе сортировки: ключевой путь, имя селектора и порядок сортировки. Мы даже можем сериализовать и десериализовать NSSortDescriptor, используя NSSecureCoding. Наш подход на основе функций не может этого сделать.

Тем не менее, подход использования функций как данных — хранения их в массивах и построения этих массивов во время выполнения — открывает новый уровень динамического поведения, и это один из способов, с помощью которого статически типизированный язык, ориентированный на компиляцию, такой как Swift, может воспроизводить некоторые динамические поведения языков, таких как Objective-C или Ruby.

Мы также увидели полезность написания функций, которые комбинируют другие функции, что является одним из строительных блоков функционального программирования. Например, наш метод then взял два дескриптора сортировки и объединил их в один дескриптор сортировки. Это очень мощная техника с множеством различных применений.

Функции как делегаты Link to heading

Делегаты. Они повсюду. В головы программистов на Objective-C (и Java) вбивается следующее сообщение: используйте протоколы (интерфейсы) для обратных вызовов. Вы определяете протокол, ваш объект реализует этот протокол, и он регистрирует себя в качестве вашего делегата, чтобы получать обратные вызовы.

Если протокол делегата содержит только один метод, вы можете механически заменить свойство, хранящее объект делегата, на то, которое хранит функцию обратного вызова напрямую. Однако есть ряд компромиссов, которые следует учитывать.

Делегаты, стиль Cocoa Link to heading

Начнем с создания протокола так же, как это делает Cocoa, определяя свои бесчисленные протоколы делегатов. Большинство программистов, пришедших из Objective-C, писали код подобным образом много раз:

protocol AlertViewDelegate: AnyObject {
    func buttonTapped(atIndex: Int)
}

Протокол AlertViewDelegate определен как протокол, предназначенный только для классов (наследуясь от AnyObject), потому что мы хотим, чтобы наш класс AlertView хранил слабую ссылку на делегата. Таким образом, нам не нужно беспокоиться о циклах ссылок. AlertView никогда не будет сильно удерживать своего делегата, поэтому даже если делегат (прямо или косвенно) имеет сильную ссылку на AlertView, все будет в порядке. Если делегат будет деинициализирован, свойство делегата автоматически станет nil:

class AlertView {
    var buttons: [String]
    weak var delegate: AlertViewDelegate?
    
    init(buttons: [String] = ["OK", "Cancel"]) {
        self.buttons = buttons
    }
    
    func fire() {
        delegate?.buttonTapped(atIndex: 1)
    }
}

Этот паттерн очень хорошо работает, когда мы имеем дело с классами. Например, предположим, что у нас есть класс ViewController, который инициализирует AlertView и устанавливает себя в качестве делегата. Поскольку делегат помечен как weak, нам не нужно беспокоиться о циклах ссылок:

class ViewController: AlertViewDelegate {
    let alert: AlertView
    
    init() {
        alert = AlertView(buttons: ["OK", "Cancel"])
        alert.delegate = self
    }
    
    func buttonTapped(atIndex index: Int) {
        print("Button tapped: \(index)")
    }
}

Общепринятой практикой является всегда помечать свойства делегатов как weak. Эта конвенция упрощает понимание управления памятью, поскольку классы, реализующие протокол делегата, не должны беспокоиться о создании цикла ссылок.

Функции вместо делегатов Link to heading

Если протокол делегата определяет только один метод, мы можем заменить свойство делегата на свойство, которое напрямую хранит функцию обратного вызова. В нашем случае это может быть необязательное свойство buttonTapped, которое по умолчанию равно nil:

class AlertView {
    var buttons: [String]
    var buttonTapped: (( _ buttonIndex: Int) -> ())?
    
    init(buttons: [String] = ["OK", "Cancel"]) {
        self.buttons = buttons
    }
    
    func fire() {
        buttonTapped?(1)
    }
}

Запись (_ buttonIndex: Int) -> () для типа функции выглядит немного странно, потому что внутреннее имя buttonIndex не имеет значения в остальной части кода. Мы упоминали выше, что типы функций, к сожалению, не могут иметь метки параметров; однако они могут иметь явную пустую метку параметра, объединенную с внутренним именем аргумента. Это официально одобренный обходной путь, чтобы дать параметрам в типах функций метки для целей документации, пока Swift не поддерживает лучший способ.

Теперь мы можем создать структуру логгера, а затем создать экземпляр AlertView и переменную логгера:

struct TapLogger {
    var taps: [Int] = []
    
    mutating func logTap(index: Int) {
        taps.append(index)
    }
}

let alert = AlertView()
var logger = TapLogger()

Однако мы не можем просто присвоить метод logTap свойству buttonTapped. Компилятор Swift сообщает нам, что “частичное применение ‘изменяющего’ метода не допускается”:

alert.buttonTapped = logger.logTap // Ошибка

В приведенном выше коде неясно, что должно произойти при присвоении. Логгер копируется? Или buttonTapped должен изменять оригинальную переменную (т.е. логгер захватывается)?

Чтобы это работало, нам нужно обернуть правую часть присвоения в замыкание. Это имеет преимущество в том, что теперь очень ясно, что мы захватываем оригинальную переменную логгера (а не значение), и что мы ее изменяем:

alert.buttonTapped = { logger.logTap(index: $0) }

В качестве дополнительного преимущества, именование теперь разъединено: свойство обратного вызова называется buttonTapped, но функция, которая его реализует, называется logTap. Вместо метода мы также можем указать анонимную функцию:

alert.buttonTapped = { print("Button \($0) was tapped") }

При комбинировании обратных вызовов с классами есть некоторые предостережения. Вернемся к нашему примеру контроллера представления. В его инициализаторе, вместо того чтобы назначать себя делегатом AlertView, контроллер представления теперь может назначить свой метод buttonTapped в качестве обработчика обратного вызова AlertView:

class ViewController {
    let alert: AlertView
    
    init() {
        alert = AlertView(buttons: ["OK", "Cancel"])
        alert.buttonTapped = self.buttonTapped(atIndex:)
    }
    
    func buttonTapped(atIndex index: Int) {
        print("Button tapped: \(index)")
    }
}

Строка alert.buttonTapped = self.buttonTapped(atIndex:) выглядит как невинное присвоение, но будьте осторожны: мы только что создали цикл ссылок! Каждая ссылка на метод экземпляра объекта (например, self.buttonTapped в примере) неявно захватывает объект. Чтобы понять, почему это должно быть так, рассмотрим точку зрения AlertView: когда AlertView вызывает функцию обратного вызова, которая хранится в его свойстве buttonTapped, функция должна каким-то образом “знать”, метод какого объекта она должна вызывать — недостаточно просто хранить ссылку на ViewController.buttonTapped(atIndex:), не зная экземпляра.

Мы могли бы сократить self.buttonTapped(atIndex:) до self.buttonTapped или просто buttonTapped; все три ссылаются на одну и ту же функцию. Метки параметров могут быть опущены, если это не создает неоднозначностей.

Чтобы избежать сильной ссылки, часто необходимо обернуть вызов метода в другое замыкание, которое захватывает объект слабо:

alert.buttonTapped = { [weak self] index in
    self?.buttonTapped(atIndex: index)
}

Таким образом, у AlertView не будет сильной ссылки на контроллер представления. Если мы можем гарантировать, что время жизни AlertView связано с контроллером представления, другой вариант — использовать unowned вместо weak. При использовании weak, если AlertView переживет контроллер представления, self будет nil внутри замыкания, когда функция будет вызвана.

Как мы видели, существуют определенные компромиссы между протоколами и функциями обратного вызова. Протокол добавляет некоторую многословность, но протокол, основанный только на классах, с слабым делегатом устраняет необходимость беспокоиться о создании циклов ссылок. Замена делегата на функцию добавляет много гибкости и позволяет использовать структуры и анонимные функции. Однако при работе с классами нужно быть осторожным, чтобы не создать цикл ссылок.

Кроме того, когда вам нужно несколько функций обратного вызова, которые тесно связаны (например, при предоставлении данных для таблицы), может быть полезно держать их сгруппированными в протоколе, а не иметь отдельные обратные вызовы. С другой стороны, при использовании протокола один тип должен реализовать все методы.

Чтобы отменить регистрацию делегата или функции обратного вызова, мы можем установить его в nil. Что насчет случаев, когда наш тип хранит массив делегатов или обратных вызовов? С делегатами на основе классов мы можем удалить объект из списка делегатов. С функциями обратного вызова это не так просто; нам нужно будет добавить дополнительную инфраструктуру для отмены регистрации, потому что функции не могут быть сравнены.

Параметры inout и изменяющие методы Link to heading

Знак “&”, который мы используем перед аргументом inout в Swift, может создать у вас впечатление — особенно если у вас есть опыт работы с C или C++ — что параметры inout по сути являются передачей по ссылке. Но это не так. inout — это передача по значению с последующим копированием обратно, а не передача по ссылке. Как говорится в книге The Swift Programming Language:

Параметр inout имеет значение, которое передается в функцию, модифицируется функцией и возвращается из функции для замены оригинального значения.

Чтобы понять, какие выражения могут быть переданы в качестве параметра inout, нам нужно провести различие между l-значениями и r-значениями. L-значение описывает местоположение в памяти. L-значение — это сокращение от “left value” (левое значение), потому что l-значения — это выражения, которые могут появляться с левой стороны оператора присваивания. Например, array[0] является l-значением, так как оно описывает местоположение в памяти первого элемента в массиве. R-значение описывает значение. 2 + 2 является r-значением, так как оно описывает значение 4. Вы не можете поставить 2 + 2 или 4 на левую сторону оператора присваивания.

Для параметров inout вы можете передавать только l-значения, потому что не имеет смысла изменять r-значение. Когда вы работаете с параметрами inout в обычных функциях и методах, вам нужно явно указывать их: каждое l-значение должно быть предварено знаком &. Например, когда мы вызываем функцию increment (которая принимает inout Int), мы можем передать переменную, предварив ее амперсандом:

func increment(value: inout Int) {
    value += 1
}

var i = 0
increment(value: &i)

Если мы определяем переменную с помощью let, мы не можем использовать ее как l-значение. Это имеет смысл, потому что нам не разрешается изменять переменные let; мы можем использовать только “изменяемые” l-значения:

let y: Int = 0
increment(value: &y) // Ошибка

Кроме переменных, несколько других вещей также являются l-значениями. Например, мы также можем передать индекс массива (если массив определен с помощью var):

var array = [0, 1, 2]
increment(value: &array[0])
array // [1, 1, 2]

На самом деле, это работает с каждым индексом (включая ваши собственные пользовательские индексы), при условии, что у них определены как get, так и set. Точно так же мы можем использовать свойства как l-значения, но опять же, только если у них определены как get, так и set:

struct Point {
    var x: Int
    var y: Int
}

var point = Point(x: 0, y: 0)
increment(value: &point.x)
point // Point(x: 1, y: 0)

Если свойство является только для чтения (то есть доступен только get), мы не можем использовать его как параметр inout:

extension Point {
    var squaredDistance: Int {
        return x * x + y * y
    }
}

increment(value: &point.squaredDistance) // Ошибка

Операторы также могут принимать значение inout, но для простоты они не требуют амперсанда при вызове; мы просто указываем l-значение. Например, давайте добавим обратно оператор постфиксного инкремента, который был удален в Swift 3:

postfix func ++(x: inout Int) {
    x += 1
}

point.x++
point // Point(x: 2, y: 0)

Изменяющий оператор может даже быть объединен с опциональной цепочкой. Здесь мы связываем операцию инкремента с доступом к индексу словаря:

var dictionary = ["one": 1]
dictionary["one"]?++
dictionary["one"] // Optional(2)

Обратите внимание, что оператор ++ не будет выполнен, если поиск ключа вернет nil.

Компилятор может оптимизировать переменную inout, чтобы передавать ее по ссылке, а не копировать. Однако в документации явно указано, что не следует полагаться на это поведение.

Мы вернемся к inout в следующей главе о структурах и классах, где мы рассмотрим сходства между изменяющими методами и функциями, которые принимают параметр inout.

Вложенные функции и inout Link to heading

Вы можете использовать параметр inout внутри вложенных функций, и Swift гарантирует, что ваше использование безопасно. Например, вы можете определить вложенную функцию (либо с помощью func, либо с помощью выражения замыкания) и безопасно изменять параметр inout:

func incrementTenTimes(value: inout Int) {
  func inc() {
    value += 1
  }
  for _ in 0..<10 {
    inc()
  }
}

var x = 0
incrementTenTimes(value: &x)
x // 10

Однако вам не разрешается позволять этому параметру inout “выходить за пределы” (мы поговорим об этом позже в этой главе):

func escapeIncrement(value: inout Int) -> () -> () {
  func inc() {
    value += 1
  }
  // Ошибка: вложенная функция не может захватывать параметр inout
  // и выходить за пределы.
  return inc
}

Это имеет смысл, учитывая, что значение inout копируется обратно непосредственно перед возвратом функции. Если бы мы могли каким-то образом изменить его позже, что должно произойти? Должно ли значение быть скопировано обратно в какой-то момент? Что, если источник больше не существует? Проверка этого компилятором критически важна для безопасности.

Когда&Неозначаетinout Link to heading

Говоря об небезопасных функциях, вы должны знать о другом значении & : преобразование аргумента функции в небезопасный указатель. Если функция принимает UnsafeMutablePointer в качестве параметра, то вы можете передать в нее переменную, используя &, аналогично тому, как вы бы сделали это с аргументом inout. Но здесь вы действительно передаете по ссылке — фактически по указателю.

Вот функция incref, написанная для принятия небезопасного изменяемого указателя вместо inout:

func incref(pointer: UnsafeMutablePointer<Int>) -> () -> Int {
    // Сохраняем копию указателя в замыкании.
    return {
        pointer.pointee += 1
        return pointer.pointee
    }
}

Как мы обсудим в последующих главах, массивы Swift неявно преобразуются в указатели, чтобы сделать совместимость с C приятной и безболезненной. Теперь предположим, что вы передаете массив, который выходит из области видимости до того, как вы вызовете результирующую функцию:

let fun: () -> Int
do {
    var array = [0]
    fun = incref(pointer: &array)
}
/*_*/ fun()

Это открывает захватывающий мир неопределенного поведения. В тестировании приведенный выше код выводил разные значения при каждом запуске: иногда 0, иногда 1, иногда 140362397107840 — и иногда он вызывал сбой во время выполнения.

Мораль здесь такова: знайте, что вы передаете. При добавлении & вы можете вызывать безопасную семантику inout Swift, или вы можете приводить вашу бедную переменную в жестокий мир небезопасных указателей. При работе с небезопасными указателями будьте очень осторожны с временем жизни переменных. Мы подробнее рассмотрим это в главе о совместимости.

Индексы Link to heading

Мы уже видели индексы в стандартной библиотеке. Например, мы можем выполнить поиск в словаре следующим образом: dictionary[key]. Эти индексы представляют собой гибрид функций и свойств, с их собственной специальной синтаксисом. Как и функции, они принимают аргументы. Как и вычисляемые свойства, они могут быть либо только для чтения (используя get), либо для чтения и записи (используя get set). Точно так же, как и обычные функции, мы можем перегружать их, предоставляя несколько вариантов с разными типами — что невозможно сделать со свойствами. Например, массивы по умолчанию имеют два индекса — один для доступа к отдельному элементу и один для получения среза (если быть точным, они объявлены в протоколе Collection):

let fibs = [0, 1, 1, 2, 3, 5]
let first = fibs[0] // 0
fibs[1..<3] // [1, 1]

Пользовательские подскрипты Link to heading

Мы можем добавить поддержку подскриптов для наших собственных типов, а также можем расширить существующие типы новыми перегрузками подскриптов. В качестве примера давайте определим подскрипт для Collection, который принимает список индексов и возвращает массив всех элементов по этим индексам:

extension Collection {
    **subscript** (indices indexList: Index...) -> [Element] {
        var result: [Element] = []
        for index in indexList {
            result.append(self[index])
        }
        return result
    }
}

Обратите внимание, как мы использовали явный метку параметра, чтобы различить наш подскрипт от тех, что в стандартной библиотеке. Три точки указывают на то, что indexList является вариативным параметром. Вызывающий код может передать ноль или более значений, разделенных запятыми, указанного типа (в данном случае, типа Index коллекции). Внутри функции параметры становятся доступными в виде массива.

Мы можем использовать новый подскрипт следующим образом:

Array("abcdefghijklmnopqrstuvwxyz")[indices: 7, 4, 11, 11, 14]
// ["h", "e", "l", "l", "o"]

Расширенные подскрипты Link to heading

Подскрипты не ограничены одним параметром. Мы уже видели пример подскрипта, который принимает более одного параметра: подскрипт словаря, который принимает ключ и значение по умолчанию. Ознакомьтесь с его реализацией в исходном коде Swift, если вам это интересно.

Подскрипты также могут быть обобщенными в своих параметрах или возвращаемом типе. Рассмотрим гетерогенный словарь типа [String: Any]:

var japan: [String: Any] = [
    "name": "Japan",
    "capital": "Tokyo",
    "population": 126_440_000,
    "coordinates": [
        "latitude": 35.0,
        "longitude": 139.0
    ]
]

Если вы хотите изменить вложенное значение в этом словаре, например, широту координат, вы обнаружите, что это не так просто:

// Ошибка: Тип 'Any' не имеет членов подскрипта.
japan["coordinates"]?["latitude"] = 36.0

Хорошо, это понятно. Выражение japan["coordinates"] имеет тип Any?, поэтому вы, вероятно, попытаетесь привести его к словарю перед применением вложенного подскрипта:

// Ошибка: Невозможно присвоить значение неизменяемому выражению.
(japan["coordinates"] as? [String: Double])?["latitude"] = 36.0

Увы, это не только становится быстро неаккуратным, но и не работает. Проблема в том, что вы не можете изменить переменную через приведение типа — выражение japan["coordinates"] as? [String: Double] больше не является lvalue. Вам придется сначала сохранить вложенный словарь в локальную переменную, затем изменить эту переменную, а затем присвоить локальную переменную обратно на верхний уровень ключа.

Мы можем сделать лучше, расширив Dictionary с помощью обобщенного подскрипта, который принимает желаемый целевой тип в качестве второго параметра и пытается выполнить приведение внутри реализации подскрипта:

extension Dictionary {
    subscript<Result>(key: Key, as type: Result.Type) -> Result? {
        get {
            return self[key] as? Result
        }
        set {
            // Удалить существующее значение, если вызывающий передал nil.
            guard let value = newValue else {
                self[key] = nil
                return
            }
            // Игнорировать, если типы не совпадают.
            guard let value2 = value as? Value else {
                return
            }
            self[key] = value2
        }
    }
}

Поскольку нам больше не нужно выполнять приведение типа для значения, возвращаемого подскриптом, операция изменения проходит через верхний уровень переменной словаря:

japan["coordinates", as: [String: Double].self]?["latitude"] = 36.0
japan["coordinates"] // Optional(["latitude": 36.0, "longitude": 139.0])

Приятно, что обобщенные подскрипты делают это возможным, но вы заметите, что финальный синтаксис в этом примере все еще довольно неаккуратен. Swift, как правило, не очень подходит для работы с гетерогенными коллекциями, такими как этот словарь. В большинстве случаев вам будет лучше определить свои собственные пользовательские типы для ваших данных (например, здесь — структуру Country) и привести эти типы к Codable для преобразования значений в форматы передачи данных и обратно.

Автозакрытия Link to heading

Мы все знакомы с тем, как логический оператор И (&&) оценивает свои аргументы. Сначала он оценивает левый операнд и немедленно возвращает результат, если это значение равно false. Только если левый операнд оценивается как true, происходит оценка правого операнда. В конце концов, если левый операнд равен false, нет никакой возможности, чтобы всё выражение оценивалось как true. Это поведение называется “короткое замыкание”. Например, если мы хотим проверить, выполняется ли условие для первого элемента массива, мы могли бы написать следующий код:

let evens = [2, 4, 6]
if !evens.isEmpty && evens[0] > 10 {
    // Выполнить какую-то работу.
}

В приведённом выше фрагменте мы полагаемся на короткое замыкание: поиск в массиве происходит только в том случае, если первое условие выполняется. Без короткого замыкания этот код вызвал бы ошибку при работе с пустым массивом. Лучший способ написать этот конкретный пример — использовать привязку if let:

if let first = evens.first, first > 10 {
    // Выполнить какую-то работу.
}

Это ещё одна форма короткого замыкания: второе условие оценивается только в том случае, если первое условие успешно.

В почти всех языках программирования короткое замыкание для операторов && и || встроено в язык. Однако часто невозможно определить свои собственные операторы или функции, которые имеют такое же поведение. Если язык поддерживает функции первого класса, мы можем имитировать короткое замыкание, предоставляя анонимную функцию вместо значения. Например, предположим, что мы хотим определить функцию and в Swift, чтобы она имела такое же поведение, как оператор &&:

func and(_ l: Bool, _ r: () -> Bool) -> Bool {
    guard l else { return false }
    return r()
}

Функция выше сначала проверяет значение l и возвращает false, если l оценивается как false. Только если l равно true, она возвращает значение, которое возвращает замыкание r. Однако использование этой функции немного менее удобно, чем использование оператора &&, потому что правый операнд теперь должен быть функцией:

if and(!evens.isEmpty, { evens[0] > 10 }) {
    // Выполнить какую-то работу.
}

В Swift есть хорошая возможность сделать это более элегантным. Мы можем использовать атрибут @autoclosure, чтобы сказать компилятору, что он должен обернуть определённый аргумент в выражение замыкания. Определение and почти такое же, как и выше, за исключением добавленного аннотации @autoclosure:

func and(_ l: Bool, _ r: @autoclosure () -> Bool) -> Bool {
    guard l else { return false }
    return r()
}

Однако использование and теперь гораздо проще, так как нам не нужно оборачивать второй параметр в замыкание. Мы можем просто вызывать его так, как если бы он принимал обычный аргумент типа Bool, а компилятор прозрачно оборачивает аргумент в выражение замыкания:

if and(!evens.isEmpty, evens[0] > 10) {
    // Выполнить какую-то работу.
}

Это позволяет нам определять собственные функции и операторы с поведением короткого замыкания. Например, операторы, такие как ?? и !? (как определено в главе о Опционалах), теперь легко писать. В стандартной библиотеке функции, такие как assert и precondition, также используют автозакрытия, чтобы оценивать аргументы только тогда, когда это действительно необходимо. Откладывая оценку условий утверждения с места вызова на тело функции assert, эти потенциально дорогостоящие операции могут быть полностью исключены в оптимизированных сборках, где они не нужны.

Автозакрытия также могут быть полезны при написании функций логирования. Например, вот как вы могли бы написать свою собственную функцию log, которая оценивает сообщение лога только в том случае, если условие истинно:

func log(ifFalse condition: Bool,
          message: @autoclosure () -> String,
          file: String = #fileID, function: String = #function, line: Int = #line) {
    guard !condition else { return }
    print("Assertion failed: \(message()), \(file):\(function) (line \(line))")
}

Это означает, что вы можете выполнять дорогостоящие вычисления в выражении, которое вы передаёте в качестве аргумента message, не неся затрат на оценку, если значение не используется. Функция log также использует идентификаторы отладки #fileID, #function и #line. Они особенно полезны, когда передаются в качестве значений по умолчанию для функции, потому что они получат значения имени файла, имени функции и номера строки в месте вызова.

Тем не менее, используйте автозакрытия с осторожностью. Их поведение нарушает обычные ожидания — например, если побочный эффект выражения не выполняется, потому что выражение обёрнуто в автозакрытие. Как говорит книга Apple по Swift:

Чрезмерное использование автозакрытий может сделать ваш код трудным для понимания. Контекст и имена функций должны ясно указывать на то, что оценка откладывается.

Аннотация @escaping Link to heading

Вы могли заметить, что компилятор требует от вас явного указания на использование self в некоторых выражениях замыканий, но не в других. Например, нам нужно использовать явное self в обработчике завершения сетевого запроса, в то время как нам не нужно быть явными относительно self в замыканиях, передаваемых в функции map или filter. Разница между ними заключается в том, сохраняется ли замыкание для последующего использования (как в случае сетевого запроса) или используется только синхронно в пределах области видимости функции (как в случае с map и filter).

Если замыкание сохраняется где-то (например, в свойстве) для последующего вызова, оно называется escaping. Напротив, замыкания, которые никогда не покидают локальную область видимости функции, являются non-escaping. В случае escaping замыканий компилятор заставляет нас явно указывать использование self в выражениях замыканий, потому что непреднамеренное сильное захватывание self является одной из самых частых причин циклов ссылок. Non-escaping замыкание не может создать постоянный цикл ссылок, потому что оно автоматически уничтожается, когда функция, в которой оно определено, возвращает результат.

Аргументы замыканий по умолчанию являются non-escaping. Если вы хотите сохранить замыкание для последующего использования, вам нужно пометить аргумент замыкания как @escaping. Компилятор это проверит: если вы не пометите аргумент замыкания как @escaping, он не позволит вам сохранить замыкание (или вернуть его вызывающему, например).

В примере с дескрипторами сортировки было несколько параметров функции, которые требовали атрибута @escaping:

extension SortDescriptor {
    init<Value: Comparable>( _ key: @escaping (Root) -> Value) {
        self.areInIncreasingOrder = { key($0) < key($1) }
    }
}

Обратите внимание, что правило о non-escaping по умолчанию применяется только к параметрам функции, и только для типов функции в непосредственной позиции параметра. Это означает, что сохраненные свойства, имеющие тип функции, всегда являются escaping (что имеет смысл). Удивительно, но то же самое верно для функций, которые используются в качестве параметров, но обернуты в какой-то другой тип, такой как кортеж или опционал. Поскольку замыкание больше не является непосредственным параметром в этом случае, оно автоматически становится escaping. В результате вы не можете написать функцию, которая принимает аргумент функции, где параметр является одновременно опциональным и non-escaping. Во многих ситуациях вы можете избежать того, чтобы делать аргумент опциональным, предоставив значение по умолчанию для замыкания. Если это невозможно, обходным путем является использование перегрузки для написания двух вариантов функции — одного с опциональным (escaping) параметром функции и одного с не опциональным, non-escaping параметром:

func transform( _ input: Int, with f: ((Int) -> Int)?) -> Int {
    print("Используется опциональная перегрузка")
    guard let f = f else { return input }
    return f(input)
}

func transform( _ input: Int, with f: (Int) -> Int) -> Int {
    print("Используется не опциональная перегрузка")
    return f(input)
}

Таким образом, вызов функции с аргументом nil (или переменной опционального типа) будет использовать опциональный вариант, в то время как передача литерального выражения замыкания вызовет не опциональную, non-escaping перегрузку:

_ = transform(10, with: nil) // Используется опциональная перегрузка
_ = transform(10) { $0 * $0 } // Используется не опциональная перегрузка

withoutActuallyEscaping Link to heading

Вы можете столкнуться с ситуацией, когда вы знаете, что замыкание не покидает контекст, но компилятор не может это доказать, заставляя вас добавлять аннотацию @escaping. Чтобы проиллюстрировать это, давайте рассмотрим пример из документации стандартной библиотеки. Мы пишем собственную реализацию метода allSatisfy для массива, который использует ленивый вид массива (не путать с ленивыми свойствами, которые мы обсуждаем в главе о свойствах) внутри. Затем мы применяем фильтр к ленивому виду и проверяем, прошло ли какое-либо значение через фильтр (т.е. удовлетворяет ли хотя бы один элемент предикату). Наша первая попытка приводит к ошибке компиляции:

extension Array {
    func allSatisfy2(_ predicate: (Element) -> Bool) -> Bool {
        // Ошибка: Использование замыкания с параметром, не покидающим контекст, 'predicate'
        // может позволить ему покинуть контекст.
        return self.lazy.filter({ !predicate($0) }).isEmpty
    }
}

Мы скажем больше о ленивых коллекциях в главе о протоколах коллекций. На данный момент достаточно знать, что ленивые виды хранят последующие преобразования (например, замыкание, переданное в filter) во внутреннем свойстве, чтобы применить их позже. Это требует, чтобы любое замыкание, которое передается, было помечено как escaping, и это является причиной ошибки, поскольку наш параметр predicate не является escaping.

Мы могли бы исправить это, аннотировав параметр @escaping, но в этом случае мы знаем, что замыкание не покинет контекст, поскольку срок жизни ленивой коллекции связан со сроком жизни функции. Swift предоставляет выход из этой ситуации в виде функции withoutActuallyEscaping. Она позволяет вам передать замыкание, не покидающее контекст, в функцию, которая ожидает замыкание, покидающее контекст. Это компилируется и работает корректно:

extension Array {
    func allSatisfy2(_ predicate: (Element) -> Bool) -> Bool {
        return withoutActuallyEscaping(predicate) { escapablePredicate in
            self.lazy.filter { !escapablePredicate($0) }.isEmpty
        }
    }
}

let areAllEven = [1, 2, 3, 4].allSatisfy2 { $0 % 2 == 0 } // false
let areAllOneDigit = [1, 2, 3, 4].allSatisfy2 { $0 < 10 } // true

Обратите внимание, что ленивое выполнение не является более эффективным, чем реализация allSatisfy в стандартной библиотеке, которая использует простой цикл for и не требует withoutActuallyEscaping. Ленивое выполнение служит только для демонстрации случая, когда мы знаем, что замыкание не покинет контекст, но компилятор не может это доказать.

Имейте в виду, что вы входите в небезопасную область, используя withoutActuallyEscaping. Позволяя копии замыкания покинуть контекст вызова withoutActuallyEscaping, вы получаете неопределенное поведение.

Строители Результатов Link to heading

Строители результатов — это особый вид функций, которые позволяют нам создавать значения результата из множества операторов, используя лаконичный и выразительный синтаксис. Наиболее ярким примером, и, возможно, мотивацией для этой функции Swift, является синтаксис строителя представлений SwiftUI. Используя строителей представлений, вы можете определить содержимое, например, горизонтального стека представлений, следующим образом:

HStack {
    Text("Завершите обновление Advanced Swift")
    Spacer()
    Button("Завершить") { /* ... */ }
}

Замыкание с правой стороны HStack является функцией строителя результата, хотя оно не аннотировано никаким особым образом. Аннотация — @ViewBuilder — может быть найдена в инициализаторе HStack, который мы немного упростили для этой примера:

struct HStack<Content>: View where Content: View {
    public init (
        alignment: VerticalAlignment = .center,
        spacing: CGFloat? = nil ,
        @ViewBuilder content: () -> Content)
    // ...
}

В строителе представлений выше мы написали три выражения на отдельных строках. В обычном коде Swift это не имело бы смысла: мы ничего не делаем с значениями этих выражений, и у них также нет побочных эффектов. Однако внутри функции строителя результата компилятор переписывает этот код, чтобы создать составное значение из всех операторов в функции. Для этого он использует статические методы, определенные в соответствующем типе строителя результата, как, например, ViewBuilder в этом примере.

Чтобы переписать приведенный выше пример, компилятор использует статический метод buildBlock на ViewBuilder, который принимает три параметра, соответствующих протоколу View:

**@resultBuilder public struct** ViewBuilder {
    // ...
    **public static func** buildBlock<C0, C1, C2>( _ c0: C0, _ c1: C1, _ c2: C2)
    -> TupleView<(C0, C1, C2)>
    where C0: View, C1: View, C2: View
    // ...
}

Код, написанный без использования строителей результатов, выглядит следующим образом:

HStack {
    return ViewBuilder.buildBlock(
        Text("Завершите обновление Advanced Swift"),
        Spacer(),
        Button("Завершить") { /* ... */ }
    )
}

Типы строителей результатов помечены @resultBuilder и могут реализовывать различные статические методы build ..., которые мы рассмотрим более подробно в оставшейся части этого раздела. То, какие из этих методов реализованы, определяет, какие виды выражений и операторов могут быть использованы в функции строителя результата.

BlocksandExpressions Link to heading

Самые базовые методы сборки — это buildBlock и buildExpression. Как и все методы сборки, они являются статическими методами. Тип сборщика просто служит пространством имен и никогда не инстанцируется.

Реализация хотя бы одного метода buildBlock является единственным формальным требованием для типа @resultBuilder. Чаще всего вы будете реализовывать более одной вариации buildBlock, отличающейся количеством и, возможно, типами параметров, так как это позволяет комбинировать несколько частичных результатов в одно итоговое значение. Например, метод buildBlock сборщика представлений имеет варианты от нуля до десяти параметров, что позволяет комбинировать от нуля до десяти представлений в TupleView в функции сборщика представлений.

Методы buildBlock в SwiftUI принимают только значения типа View в качестве аргументов, но это не общее требование для buildBlock, чтобы ограничиваться одним типом аргумента. Мы также можем написать несколько перегрузок с разными типами параметров, хотя реализация buildExpression часто является более элегантным способом поддерживать несколько типов в функции сборщика.

buildExpression не является обязательным для типов сборщиков, но может быть очень полезным для поддержки различных типов выражений. Когда вы реализуете один или несколько вариантов этого метода, Swift применит buildExpression к каждому выражению в функции сборщика сначала, прежде чем передать частичные результаты в buildBlock.

Метод buildExpression принимает один параметр, но вы можете реализовать несколько вариантов для поддержки различных типов параметров. Возвращаемое значение может быть любого типа, при условии, что этот тип поддерживается каким-либо методом buildBlock.

Прежде чем мы рассмотрим другие методы build ..., которые могут быть реализованы для типов сборщиков результатов, мы используем buildBlock и buildExpression и создадим свой собственный тип сборщика результатов. В качестве примера мы реализуем сборщик результатов для построения строк. В своей самой простой форме тип сборщика строк выглядит так:

@resultBuilder
struct StringBuilder {
    static func buildBlock() -> String {
        ""
    }
}

Реализуя buildBlock без параметров, мы поддерживаем функции сборки пустых строк, как эта:

@StringBuilder
func build() -> String {
}

Результатом выполнения этой функции является пустая строка. Под капотом компилятор переписывает функцию build на:

func build_rewritten() -> String {
    StringBuilder.buildBlock()
}

Чтобы поддержать построение строки из нескольких строк, мы добавляем вариант buildBlock, который принимает переменное количество строковых аргументов (переменный список аргументов также принимает ноль аргументов, так что это может заменить предыдущий метод без параметров):

static func buildBlock(_ strings: String...) -> String {
    strings.joined()
}

Переменный параметр охватывает все от нуля до любого количества строковых аргументов с помощью одного метода. Это работает для нашего примера, потому что мы ожидаем, что все аргументы будут одного типа. В отличие от этого, сборщик представлений SwiftUI предоставляет отдельные перегрузки buildBlock для различных количеств параметров и, таким образом, искусственно ограничен десятью представлениями (потому что Apple решила остановиться на этом). SwiftUI делает это таким образом, потому что каждый аргумент может быть разного типа (каждый соответствует View), и фреймворк хочет сохранить эти типы. Мы ожидаем, что будущий релиз Swift поддержит форму вариативных обобщений, что позволит SwiftUI (и другим) предоставить вариативную перегрузку buildBlock, которая принимает обобщенные аргументы.

Теперь мы можем написать функцию сборщика строк, как эту:

@StringBuilder
func greeting() -> String {
    "Hello, "
    "World!"
}

greeting() // Hello, World!

Swift переводит эту функцию сборщика строк в следующий код:

func greeting_rewritten() -> String {
    StringBuilder.buildBlock(
        "Hello, ",
        "World!"
    )
}

Далее мы можем добавить поддержку для других типов — целых чисел, например — реализуя buildExpression:

static func buildExpression(_ s: String) -> String {
    s
}

static func buildExpression(_ x: Int) -> String {
    "\(x)"
}

Обратите внимание, что мы должны реализовать buildExpression для всех типов, которые мы хотим поддерживать в качестве выражений — не только для тех, для которых нет подходящего метода buildBlock.

Теперь мы можем без проблем смешивать строки и целые числа для построения строкового результата:

let planets = [
    "Mercury", "Venus", "Earth", "Mars", "Jupiter",
    "Saturn", "Uranus", "Neptune"
]

@StringBuilder
func greetEarth() -> String {
    "Hello, Planet "
    planets.firstIndex(of: "Earth")!
    "!"
}

greetEarth() // Hello, Planet 2!

Вот переписанный код для этого примера:

func greetEarth_rewritten() -> String {
    StringBuilder.buildBlock(
        StringBuilder.buildExpression("Hello, Planet "),
        StringBuilder.buildExpression(planets.firstIndex(of: "Earth")!),
        StringBuilder.buildExpression("!")
    )
}

Перегрузка методов Builder Link to heading

Как мы видели выше, мы можем написать несколько перегрузок для методов, таких как buildBlock или buildExpression. В основном, мы предоставляем перегрузки для поддержки различных типов в функции сборщика. Например, мы реализовали несколько методов buildExpression с разными типами параметров для поддержки строк и целых чисел в сборщике строк, а SwiftUI реализует несколько вариантов buildBlock для поддержки компоновки различного количества представлений. Однако перегрузки также могут быть использованы для включения некоторых других полезных функций.

Например, по умолчанию невозможно использовать оператор fatalError в функции сборщика, потому что он рассматривается как выражение с типом Never. Реализация варианта buildExpression для типа Never решает эту проблему (к сожалению, это не очень практично, так как компилятор отметит эту реализацию с предупреждением “Will never be executed”, которое вы, возможно, не хотите видеть в своем коде):

static func buildExpression(_ x: Never) -> String {
    fatalError()
}

Аналогично, мы не можем писать операторы print в функции сборщика, потому что print имеет тип возвращаемого значения Void. Чтобы разрешить операторы print, мы можем добавить вариант buildExpression, который принимает параметр типа Void, не влияя на результат, который собирается:

static func buildExpression(_ x: Void) -> String {
    ""
}

Более того, перегрузки buildExpression также могут быть использованы для предоставления более четкой диагностики компилятора. Например, мы можем добавить второй, более общий вариант buildExpression, чтобы предоставить более ясное сообщение об ошибке для значений неподдерживаемых типов:

@available(*, unavailable, message: "String Builders only support string and integer values")
static func buildExpression<A>(_ expression: A) -> String {
    ""
}

Поскольку существующие перегрузки для String и Int более специфичны, чем эта общая функция, компилятор будет использовать этот “ошибочный” вариант только для типов, которые мы не хотим поддерживать. В этом случае атрибут @available помечает эту реализацию как недоступную и указывает на пользовательское сообщение об ошибке.

Условные конструкции Link to heading

На данный момент наш StringBuilder более или менее представляет собой другую синтаксическую конструкцию для интерполяции строк (о которой мы говорим в главе о строках). Добавив методы buildIf и buildEither к типу сборщика, мы можем расширить его возможности и поддерживать конструкции if, if ... else и switch.

Мы начинаем с реализации метода buildIf, который позволяет поддерживать простые операторы if без ветки else. Параметр buildIf — это необязательное значение, которое будет равно nil, если условие не выполнено:

static func buildIf( _ s: String?) -> String {
    s ?? ""
}

Это позволяет нам переписать наш предыдущий пример следующим образом:

@StringBuilder func greet(planet: String) -> String {
    "Hello, Planet"
    if let idx = planets.firstIndex(of: planet) {
        " "
        idx
    }
    "!"
}

greet(planet: "Earth") // Hello, Planet 2!
greet(planet: "Sun") // Hello, Planet!

Теперь, когда мы ввели условия в функцию сборщика, переписанная версия начинает становиться более интересной:

func greet_rewritten(planet: String) -> String {
    let v0 = "Hello, Planet"
    var v1: String?
    if let idx = planets.firstIndex(of: planet) {
        v1 = StringBuilder.buildBlock(
            StringBuilder.buildExpression(" "),
            StringBuilder.buildExpression(idx)
        )
    }
    let v2 = StringBuilder.buildIf(v1)
    return StringBuilder.buildBlock(v0, v2)
}

Сначала объявляется необязательная переменная для частичного результата условия (имена переменных — v0, v1 и т. д. — являются общими именами, которые мы выбрали для этого примера). Затем Swift переписывает операторы внутри условия так же, как мы видели ранее: buildExpression вызывается для каждого выражения, а затем buildBlock вызывается со всеми частичными результатами из вызовов buildExpression. Наконец, buildIf вызывается с частичным результатом условия.

Чтобы лучше обрабатывать недопустимые входные данные для функции приветствия, поддержка if ... else была бы очень полезной. Для этого нам нужно реализовать методы сборщика buildEither(first:) и buildEither(second:).

buildEither(first:) будет вызываться с результатом первого ветвления, а buildEither(second:) будет вызываться с результатом второго ветвления. Если есть несколько связанных операторов if ... else, компилятор представляет их как вложенные вызовы buildEither. Например, рассмотрим условие, подобное этому:

if x == 0 {
    // ...
} else if x < 10 {
    // ...
} else {
    // ...
}

Мы можем записать то же самое следующим образом:

if x == 0 {
    // ...
} else {
    if x < 10 {
        // ...
    } else {
        // ...
    }
}

Оба оператора if теперь имеют одну ветку else, и они будут переписаны с использованием первой и второй вариаций buildEither.

Для примера с StringBuilder реализация buildEither крайне проста, так как нам нужно только вернуть частичный результат из первого или второго ветвления:

static func buildEither( fi rst component: String) -> String {
    component
}

static func buildEither(second component: String) -> String {
    component
}

В других случаях эти две вариации могут быть использованы для различения того, как результат преобразуется в ветвлении if или else, например, чтобы сохранить информацию о том, какая ветка была выполнена.

С добавленной поддержкой if ... else (и switch одновременно) мы можем расширить наш пример:

@StringBuilder func greet2(planet: String) -> String {
    "Hello, "
    if let idx = planets.firstIndex(of: planet) {
        switch idx {
        case 2:
            "World"
        case 1, 3:
            "Neighbor"
        default:
            "planet "
            idx + 1
        }
    } else {
        "unknown planet"
    }
    "!"
}

greet2(planet: "Earth") // Hello, World!
greet2(planet: "Mars") // Hello, Neighbor!
greet2(planet: "Jupiter") // Hello, planet 5!
greet2(planet: "Pluto") // Hello, unknown planet!

Код, как он переписан компилятором Swift для функции приветствия выше, уже становится довольно громоздким:

func greet2_rewritten(planet: String) -> String {
    let v0 = StringBuilder.buildExpression("Hello, ")
    let v1: String
    if let idx = planets.firstIndex(of: planet) {
        let v1_0: String
        switch idx {
        case 2:
            v1_0 = StringBuilder.buildEither( fi rst:
                StringBuilder.buildBlock(StringBuilder.buildExpression("World"))
            )
        case 1, 3:
            v1_0 = StringBuilder.buildEither(second:
                StringBuilder.buildEither( fi rst:
                    StringBuilder.buildBlock(StringBuilder.buildExpression("Neighbor"))
                )
            )
        default:
            let v1_0_0 = StringBuilder.buildExpression("planet")
            let v1_0_1 = StringBuilder.buildExpression(idx + 1)
            v1_0 = StringBuilder.buildEither(second:
                StringBuilder.buildEither(second:
                    StringBuilder.buildBlock(v1_0_0, v1_0_1)
                )
            )
        }
        v1 = StringBuilder.buildEither( fi rst: v1_0)
    } else {
        v1 = StringBuilder.buildEither(second:
            StringBuilder.buildBlock(
                StringBuilder.buildExpression("unknown planet")
            )
        )
    }
    let v2 = StringBuilder.buildExpression("!")
    return StringBuilder.buildBlock(v0, v1, v2)
}

Циклы Link to heading

Есть еще одно выражение, которое мы можем включить в функции построителей результатов: циклы for…in. Чтобы разрешить использование циклов, нам нужно добавить метод buildArray в наш тип построителя:

static func buildArray( _ components: [String]) -> String {
    components.joined(separator: "")
}

Это позволяет нам писать циклы следующим образом:

@StringBuilder func greet3(planet: String?) -> String {
    "Hello "
    if let p = planet {
        p
    } else {
        for p in planets.dropLast() {
            "\(p), "
        }
        "and \(planets.last!)!"
    }
}

Вызов функции greet3(planet: nil ) вернет:

// Hello Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune!

Swift берет частичный результат каждой итерации цикла и собирает их в массив. Этот массив затем передается в buildArray, чтобы построить частичный результат для всего цикла:

func greet3_rewritten(planet: String?) -> String {
    let v0 = StringBuilder.buildExpression("Hello ")
    let v1: String
    if let p = planet {
        v1 = StringBuilder.buildBlock(StringBuilder.buildExpression(p))
    } else {
        var v1_0: [String] = []
        for p in planets.dropLast() {
            let v1_0_0 = StringBuilder.buildBlock(
                StringBuilder.buildExpression("\(p), ")
            )
            v1_0.append(v1_0_0)
        }
        let v1_1 = StringBuilder.buildArray(v1_0)
        let v1_2 = "and \(planets.last!)!"
        v1 = StringBuilder.buildBlock(v1_1, v1_2)
    }
    return StringBuilder.buildBlock(v0, v1)
}

ДругиеМетодыПостроения Link to heading

Типы строителей результатов могут реализовать два дополнительных метода, которые мы можем использовать для преобразования результата, который был построен. Первый метод, buildLimitedAvailability, может быть использован для преобразования типа результата в контексте ограниченной доступности (например, если #available(...)). Например, SwiftUI использует этот метод в своем типе строителя представлений, чтобы обернуть частичный результат из контекста ограниченной доступности в обертку типа, стирающую типы, AnyView. Это необходимо, потому что тип результата контекста ограниченной доступности может содержать типы, которые недоступны вне этого контекста.

Последний метод преобразования в типах строителей результатов — это buildFinalResult: как следует из названия, этот метод применяется к результату всей функции строителя результатов. Один из случаев использования этого метода — скрыть внутренние типы, которые были использованы для построения частичных результатов от внешнего мира.

Например, строитель строк может использовать [String] в качестве внутреннего типа для построения результата, а затем преобразовать массив в строку в buildFinalResult. Это означает, что все методы построения будут иметь тип результата [String], за исключением buildFinalResult, который возвращает финализированную строку:

@resultBuilder
struct StringBuilder {
    static func buildBlock(_ x: [String]...) -> [String] { x.flatMap { $0 } }
    static func buildIf(_ x: [String]?) -> [String] { x ?? [] }
    static func buildExpression(_ x: String) -> [String] { [x] }
    static func buildExpression(_ x: Int) -> [String] { ["\(x)"] }
    static func buildExpression(_ x: Never) -> [String] {}
    static func buildExpression(_ x: Void) -> [String] { [] }
    static func buildArray(_ x: [[String]]) -> [String] { x.flatMap { $0 } }
    static func buildEither(first x: [String]) -> [String] { x }
    static func buildEither(second x: [String]) -> [String] { x }
    static func buildFinalResult(_ x: [String]) -> String { x.joined() }
}

UnsupportedStatements Link to heading

Мы видели выше, как вы можете включить определенные виды операторов в функциях построителей результатов, такие как if / if let, if … else, switch и for … in. На момент написания почти все остальные операторы — включая guard, defer, do … catch, break и continue — не поддерживаются.

Резюме Link to heading

Функции являются объектами первого класса в Swift, и обращение с функциями как с данными может сделать наш код более гибким. Мы увидели, как простые функции могут заменить определенные виды программирования во время выполнения и делегаты. Мы рассмотрели изменяющие функции и параметры inout, сабскрипты (которые на самом деле являются особым видом функции), а также атрибуты @autoclosure и @escaping. Наконец, мы рассмотрели строители результатов как особый вид функции, который позволяет нам создавать возвращаемые значения с выразительным и лаконичным синтаксисом. В следующей главе мы рассмотрим тесно связанную тему: свойства. В главах о обобщениях и протоколах мы обсудим больше способов использования функций в Swift для достижения гибкости.

Свойства Link to heading

5 Link to heading

Свойства в Swift бывают двух видов: хранимые свойства и вычисляемые свойства. Хранимые свойства хранят значения, в то время как вычисляемые свойства похожи на функции: они не предоставляют хранилище, а лишь предоставляют способ получить и (опционально) установить значение. В некотором смысле, вы можете рассматривать вычисляемые свойства как методы с другой синтаксисом.

Вы можете думать о свойствах как о переменных, которые определены для типа. Большая часть того, что мы говорим в этой главе, также относится к локальным и глобальным переменным. Переменные могут быть хранимыми или вычисляемыми, иметь наблюдателей за изменениями и использовать обертки свойств. Мы рассматриваем свойства как «особый случай» переменных, а не наоборот.

Существует две важные функции, построенные на основе свойств: ключевые пути и обертки свойств. Ключевые пути — это способ ссылаться на путь свойства, не ссылаясь на значение. Все больше библиотек принимают ключевые пути как способ написания очень лаконичного, обобщенного кода, и мы увидим несколько примеров этого в этой главе. Обертка свойства позволяет вам изменить поведение свойства с очень минимальным синтаксисом. Обертки свойств сыграли важную роль в предоставлении SwiftUI его легковесного синтаксиса.

Давайте рассмотрим различные способы определения свойств. Начнем с структуры, которая представляет GPS-трек. Она хранит все записанные точки в массиве, называемом record, который является хранимым свойством:

import CoreLocation

struct GPSTrack {
    var record: [(CLLocation, Date)] = []
}

Если мы хотим сделать свойство record доступным только для чтения снаружи, но с возможностью записи внутри, мы можем использовать модификаторы private(set) или fileprivate(set):

struct GPSTrack {
    private(set) var record: [(CLLocation, Date)] = []
}

Чтобы получить все временные метки в GPS-треке, мы создаем вычисляемое свойство:

extension GPSTrack {
    /// Возвращает все временные метки для GPS-трека.
    /// - Сложность: O(*n*), где *n* — количество записанных точек.
    var timestamps: [Date] {
        return record.map { $0.1 }
    }
}

Поскольку мы не указали сеттер, свойство timestamps является только для чтения. Результат не кэшируется; каждый раз, когда вы обращаетесь к свойству, оно вычисляет результат. Руководство по проектированию API Swift рекомендует документировать сложность каждого вычисляемого свойства, которое не является O(1), поскольку вызывающие могут предположить, что доступ к свойству дешевый.

ChangeObservers Link to heading

Мы также можем реализовать обработчики willSet и didSet для хранимых свойств и переменных, которые будут вызываться каждый раз, когда свойство устанавливается (даже если значение не изменяется). Эти обработчики вызываются непосредственно перед и после того, как новое значение сохраняется, соответственно. Один из полезных случаев — это когда представление (view) должно снова расположить себя в зависимости от определенных свойств. Вызывая setNeedsLayout в didSet, мы можем быть уверены, что это всегда произойдет. (В разделе о обертках свойств мы рассмотрим еще более короткий способ сделать это.)

class MyView: UIView {
    var pageSize: CGSize = CGSize(width: 800, height: 600) {
        didSet {
            self.setNeedsLayout()
        }
    }
}

Наблюдатели должны быть определены на месте объявления свойства — вы не можете добавить один ретроактивно в расширении. Поэтому они являются инструментом для разработчика типа, а не для пользователя. Обработчики willSet и didSet по сути являются сокращением для определения пары свойств: одного приватного хранимого свойства, которое обеспечивает хранение, и одного публичного вычисляемого свойства, чей сеттер выполняет дополнительную работу до и/или после сохранения значения в хранимом свойстве. Это принципиально отличается от механизма наблюдения за ключ-значением (KVO) в Foundation, который часто используется потребителями объекта для наблюдения за внутренними изменениями, независимо от того, намеревался ли разработчик класса на это.

Тем не менее, вы можете переопределить свойство в подклассе, чтобы добавить наблюдателя. Вот пример:

class Robot {
    enum State {
        case stopped, movingForward, turningRight, turningLeft
    }
    var state = State.stopped
}

class ObservableRobot: Robot {
    override var state: State {
        willSet {
            print("Переход от \(state) к \(newValue)")
        }
    }
}

var robot = ObservableRobot()
robot.state = .movingForward // Переход от stopped к movingForward

Это по-прежнему согласуется с природой наблюдателей изменений как внутренней характеристикой типа. Если бы это не было разрешено, подкласс мог бы достичь того же эффекта, переопределив хранимое свойство с вычисляемым сеттером, который выполняет дополнительную работу.

Разница в использовании отражена в реализации этих функций. KVO использует среду выполнения Objective-C для динамического добавления наблюдателя к сеттеру класса, что было бы невозможно реализовать в текущей версии Swift, особенно для типов значений. Наблюдение за свойствами в Swift является чисто функцией времени компиляции.

LazyStoredProperties Link to heading

Инициализация значения лениво — это такой распространенный паттерн, что Swift имеет специальное ключевое слово lazy для определения ленивых свойств. Обратите внимание, что ленивое свойство всегда должно объявляться как var, потому что его начальное значение может быть установлено только после завершения инициализации. Swift имеет строгое правило, что константы let должны иметь значение до завершения инициализации экземпляра. Модификатор lazy является очень специфической формой мемоизации.

Например, если у нас есть контроллер представления, который отображает GPSTrack, мы можем захотеть иметь предварительное изображение трека. Сделав свойство ленивым, мы можем отложить дорогостоящую генерацию изображения до тех пор, пока свойство не будет доступно в первый раз:

class GPSTrackViewController: UIViewController {
    var track: GPSTrack = GPSTrack()
    lazy var preview: UIImage = {
        for point in track.record {
            // Выполнить некоторые дорогостоящие вычисления.
        }
        return UIImage( /* ... */ )
    }()
}

Обратите внимание, как мы определили ленивое свойство: это замыкание, которое возвращает значение, которое мы хотим сохранить — в нашем случае, изображение. Когда свойство впервые запрашивается, замыкание выполняется (обратите внимание на скобки в конце), и его возвращаемое значение сохраняется в свойстве. Это распространенный паттерн для ленивых свойств, которые требуют больше одной строки для инициализации.

Поскольку ленивой переменной требуется память, мы обязаны определить ленивое свойство в определении GPSTrackViewController. В отличие от вычисляемых свойств, хранимые свойства и хранимые ленивые свойства не могут быть определены в расширении. Точно так же, в отличие от вычисляемых свойств, хранимые свойства и хранимые ленивые свойства не пересчитываются каждый раз, когда одно из этих свойств запрашивается. Например, когда свойство track изменяется, preview не будет автоматически пересчитано.

Давайте рассмотрим еще более простой пример, чтобы понять, что происходит. У нас есть структура Point, и мы храним distanceFromOrigin как ленивое вычисляемое свойство:

struct Point {
    var x: Double
    var y: Double
    private(set) lazy var distanceFromOrigin: Double = (x * x + y * y).squareRoot()
    
    init(x: Double, y: Double) {
        self.x = x
        self.y = y
    }
}

Когда мы создаем точку, мы можем получить доступ к свойству distanceFromOrigin, и оно вычислит значение и сохранит его для повторного использования. Однако, если мы затем изменим значение x, это не отразится в distanceFromOrigin:

var point = Point(x: 3, y: 4)
point.distanceFromOrigin // 5.0
point.x += 10
point.distanceFromOrigin // 5.0

Важно быть осведомленным об этом. Один из способов обойти это — пересчитывать distanceFromOrigin в наблюдателях свойств didSet для x и y, но тогда distanceFromOrigin больше не будет ленивым: оно будет вычисляться каждый раз, когда изменяется x или y. Конечно, в этом примере решение простое: мы должны были сделать distanceFromOrigin обычным (не ленивым) вычисляемым свойством с самого начала.

Доступ к ленивому свойству является мутирующей операцией, потому что начальное значение свойства устанавливается при первом доступе. Когда структура содержит ленивое свойство, любой владелец структуры, который получает доступ к ленивому свойству, должен объявить переменную, содержащую структуру, как var, потому что доступ к свойству может потенциально изменить его контейнер. Поэтому это не разрешено:

let immutablePoint = Point(x: 3, y: 4)
immutablePoint.distanceFromOrigin
// Ошибка: Невозможно использовать мутирующий геттер для неизменяемого значения.

Принуждение всех пользователей типа Point, которые хотят получить доступ к ленивому свойству, использовать var, является большим неудобством, что часто делает ленивые свойства плохим выбором для структур.

Кроме того, имейте в виду, что ключевое слово lazy не выполняет никакой синхронизации потоков. Если несколько потоков одновременно обращаются к ленивому свойству до того, как значение было вычислено, возможно, что вычисление может быть выполнено более одного раза, вместе с любыми побочными эффектами, которые может иметь это вычисление.

Обертки свойств Link to heading

Одной из основных причин добавления оберток свойств в Swift, безусловно, стало появление SwiftUI. Однако они обсуждались и до этого, и их полезность выходит за рамки только SwiftUI — как Apple, так и сообщество написали обертки свойств, которые работают в самых разных ситуациях. На самом деле, одной из мотиваций для создания оберток свойств было желание иметь возможность писать ленивые свойства в виде библиотеки, а не использовать встроенную функциональность компилятора.

По сути, обертки свойств позволяют вам изменять поведение объявлений свойств. Например, рассмотрим следующий вид SwiftUI:

struct Toggle: View {
    @Binding var isOn: Bool
    // ...
    var body: some View {
        if isOn {
            // ...
        }
    }
}

В приведенном выше коде @Binding является оберткой свойства. Вы можете использовать свойство isOn так же, как и обычное свойство типа Bool: вы можете как получать, так и устанавливать его значение. Тем не менее, поведение отличается: память хранится вне значения Toggle, что делает ее непрозрачной для представления. Вы также можете изменять значение, не находясь в методе с модификацией. Обертки свойств широко используются в SwiftUI, в основном для управления состоянием.

Вы можете использовать обертки свойств для свойств классов и структур, для локальных переменных (но не для глобальных переменных) и в аргументах функций. В конце этого раздела мы обсудим некоторые ограничения оберток свойств более подробно.

Еще одним случаем использования оберток свойств является работа с UIKit и AppKit, где часто бывает необходимо, чтобы изменение свойства инвалидировало часть представления. Вспомните код из предыдущей части этой главы, где мы используем наблюдатель изменений, чтобы инвалидировать макет представления при изменении определенного свойства:

class MyView: UIView {
    var pageSize: CGSize = CGSize(width: 800, height: 600) {
        didSet {
            self.setNeedsLayout()
        }
    }
}

Используя обертку свойства @Invalidating, добавленную в iOS 15 (и macOS 12), вы теперь можете написать этот код следующим образом: