Сказ о том как один из flatMap превратился в compactMap | Обучающий курс по разработке iOS+Swift приложений.

Swift совмещает возможности объектно-ориентированного и функционального программирования. Если объектно-ориентированная часть оттачивалась десятилетиями на Objective-C и вошла составной частью в Swift (у Objective-C и Swift практически одинаковый SDK), то часть, связанная с функциональным программированием продолжает оставаться в тени, изредка «поблескивая» отдельными довольно простыми решениями. Но вот появился прекрасный ресурс pointfree.co, посвященный исключительно функциональному программированию в Swift. Мы решили воспользоваться этим и представить вашему вниманию перевод бесплатного фрагмента, касающегося переименования одной из перегрузок (overload) функции высшего порядка flatMap в compactMap. Но это лишь повод для того, чтобы вы смогли проследить ход мысли программистов, заточенных на функциональное программирование. Столкнувшись с переименованием перегрузки (overload) функции обычный один программист лишь испытает раздражение, другой проведет методичный, но узкий анализ причины этого переименования, а гуру по функциональному программированию может сделать пару любопытных открытий, элегантно дополняющих арсенал функционального программирования на Swift.

Swift 4.1 упразднил и переименовал определенную перегрузку (overload) функции flatMap. Что делает этот flatMap отличным от других? Мы исследуем это и в результате увидим, как понимание этого различия поможет нам изучить обобщение этой операции над другими структурами и получить новый полезный код!

Введение

00:05
Для Swift 4.1 была предложено изменение, упраздняющее одну из перегрузок (overloads) flatMap, немного отличающуюся от других перегрузок flatMap, и дающее новое имя этому методу. Изменение было встречено неоднозначно, но в итоге было принято, хоть и с другим именем новой функции, предложенным сообществом.
00:37
Мы хотим рассмотреть прежде всего вопрос о том, почему такое изменение было предложено, а также почему не изначально предложенное новое имя стало поводом для дальнейших изысканий. Мы надеемся показать, что иногда именование действительно важно и позволяет нам использовать прежние интуитивные соображения по-новому и неожиданно.

Сказ о двух flatMap

01:02
С самого начала, Swift охватывал паттерны функционального программирования предоставляя функции наподобие map, filter, reduce, и flatMap в стандартной библиотеке.

01:02
Swift 1.0 поставлялся с flatMap определенной на массиве Array с известной всем нам сигнатурой:

// extension Array {
//   func flatMap<B>(_ f: @escaping (Element) -> [B]) -> [B] {
//   }
// }

01:34
Это чрезвычайно полезно для выстраивания цепочек операторов, возвращающих массивы.

01:40
Возьмём к примеру строку, содержащую список значений, разделенных запятыми и символами “начала новой строки”:

let csv = """
1,2,3,4
3,5,2
8,9,4
"""

01:49
Что если бы мы захотели обработать эту строку и извлечь все эти значения меж запятых.
01:54
Можем начать с разбивки по строкам.

csv
  .split(separator: "\n")
// ["1,2,3,4", "3,5,2", "8,9,4"]

02:03
Теперь мы хотим нырнуть в массив поглубже, чтобы продолжить разбивать каждую строчку по запятым.
02:10
Нам знакомо использование map для модификации массивов.

csv
  .split(separator: "\n")
  .map { $0.split(separator: ",") }
// [["1", "2", "3", "4"], ["3", "5", "2"], ["8", "9", "4"]]

02:19
Получаем вложенные (nested) массивы значений, а нужен-то нам «плоский» массив.
02:33
Именно это flatMap и позволяет нам сделать. Она применяет заданную функцию к каждому элементу массива и затем «выравнивает» (flatten) его.

csv
  .split(separator: "\n")
  .flatMap { $0.split(separator: ",") }
// ["1", "2", "3", "4", "3", "5", "2", "8", "9", "4"]

02:41
Вскоре после этого в Swift вводится flatMap для Optional со следующей сигнатурой:

// extension Optional {
//   func flatMap<B>(_ f: @escaping (Element) -> B?) -> B? {
//   }
// }

03:00
Это полезно для построения цепочек операторов, возвращающих Optional.

03:04

К примеру, у строки String есть “проваливающийся” (failable) инициализатор, который берет данные Data, а возвращает Optional <String>:

String(data: Data(), encoding: .utf8)
// Optional("")

Так же, как и в случае с массивами, мы можем применить map на Optionals, чтобы трансформировать «завёрнутое» значение. Допустим, мы хотим трансформировать нашу строку Optional <String> в целое число.

String(data: Data(), encoding: .utf8)
  .map(Int.init)
// Optional(nil)

03:24

На выходе мы получаем nil, поскольку мы вызываем инициализатор Int с пустой строкой на входе, но здесь есть ещё одна странность. Тип полученного значения будет Optional<Int>?

_: Int? =  String(data: Data(), encoding: .utf8)
  .map(Int.init)
// Optional значение 'Int??' не “развернуто”

03:37
Вот и нет! Применение map приводит к возникновению двойного Optional, то есть Int??. Мы применяем map над Optional, используя инициализатор, вернувший Optional, и в результате получаем вложенные Optionals! По-хорошему, надо было бы использовать flatMap.

_: Int? =  String(data: Data(), encoding: .utf8)
  .flatMap(Int.init)
// nil

03:53
Теперь это компилируется, что означает, что наше значение стало «плоским». Всё ещё возвращает nil, так что давайте дадим какие-нибудь данные.

String(data: Data([55]), encoding: .utf8)
  .flatMap(Int.init)
// Optional(7)

04:00
С flatMap мы смогли взять Optional строку, применить функцию к её развёрнутому значению, а затем взять полученный Optional результат и “выровнять” (flatten) его обратно в Optional целое.

04:10
Был ещё третий flatMap для массива Array (что способствовало размыванию смысла): он брал элементы массива, пропускал их через трансформации, возвращающие Optionals. Взглянем на массив строк.

["1", "2", "buckle", "my", "shoe"]

map, мы получаем следующее:

["1", "2", "buckle", "my", "shoe"]
  .map(Int.init)
// [{some 1}, {some 2}, nil, nil, nil]

04:30
Нам возвращается массив, где успешные преобразования завёрнуты в Optional, а неудавшиеся преобразования равны nil.

04:40
Если бы вместо этого мы применили flatMap, мы могли бы избавиться от этих nils и безопасно развернуть Ints.

["1", "2", "buckle", "my", "shoe"]
  .flatMap(Int.init)
// [1, 2]

04:47
Чрезвычайно полезно! Ведь подобные вещи нам приходится делать очень часто. Но вот эта версия flatMap немного отличается от других тем, что смешивает качества массивов с качествами Optionals.

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

csv.split(separator: "\n")
  .flatMap { $0.split(separator: ",") }
  .flatMap { Int($0) }
  .reduce(0, +)
// 41

05:51
Здесь первый flatMap отвечает за получение всех значений, разделённых запятыми и «выравнивание» их в «плоский» массив, а затем следующий flatMap пытается создать Int из строки и выбрасывает то, что преобразовать не получается. Это две очень разные разные операции, а мы используем одинаковое имя для них, и различить их сходу становится трудно.

06:12
Мы тратим много времени размышляя о типах, особенно о форме функций. Порой это может затеряться в определении метода: тип контейнера исчезает из декларации, а имена функций и аргументов способны ещё более всё затуманить. Давайте-ка изолируем сигнатуры функций от самих типов. Для этого используем свой вольный синтаксис вида (Configuration) -> (Data) -> ReturnValue:

// flatMap : ((A) -> [B]) -> ([A]) -> [B]
// flatMap : ((A) ->  B?) -> ( A?) ->  B?

// flatMap : ((A) ->  B?) -> ([A]) -> [B]

07:24
Одна из этих форм не такая, как остальные. Два верхних flatMaps оперируют над одним типом контейнера: Array или Optional, а вот третий flatMap оперирует над обоими контейнерами сразу.

07:43
Если мы избавимся от синтаксического сахара, то обобщенные (generics) перегрузки будут выглядеть так:

// flatMap : ((A) ->    Array<B>) -> (   Array<A>) ->    Array<B>
// flatMap : ((A) -> Optional<B>) -> (Optional<A>) -> Optional<B>

// flatMap : ((A) -> Optional<B>) -> (   Array<A>) ->    Array<B>

08:00
Что если представить себе контейнеры типов Array и Optional как самостоятельные обобщенные (generics) типы. Тогда мы можем выбросить их имена и получится что-то вроде этого:

// flatMap : ((A) -> M<B>) -> (M<A>) -> M<B>
// flatMap : ((A) -> M<B>) -> (M<A>) -> M<B>

// flatMap : ((A) -> N<B>) -> (M<A>) -> M<B>

08:36
Ух-ты, первые две сигнатуры оказались абсолютно равны! А вот в случае с третьей сигнатурой мы имеем дело с двумя разными обобщенными (generic) типами контейнеров и семантика становится более запутанной. Как именно из N будет получено M? В двух верхних версиях, можно понять, что есть трансформирующая функция, которая как-то осуществляет композицию контейнерных типов на новый лад. В этой версии N мало что даёт нам для дальнейшего продвижения.
09:27
Чтобы понять логику, придётся вернуться к конкретным типам.

// flatMap : ((A) -> B?) -> (M<A>) -> M<B>

Всё ещё немного запутанно. Может ли любой M работать с Optional таким образом? Может быть этот flatMap вообще не является обобщённым (generic), как другие.

Продвижение до Optional (Optional promotion)[1]

10:13
Была еще одна проблема с перегрузкой flatMap для операций с Array, возвращающих Optionals: продвижение до Optional (Optional promotion). Для целей эргономики Swift в коде автоматически “заворачивает” значения в Optional везде, где требуется Optional параметр.[2] В результате код становится более лаконичным и снимает некоторую часть нагрузки с инженера, которому иначе пришлось бы ЯВНО “заворачивать” значения с помощью .some, но выведение типа из контекста (inference) — это палка о двух концах, и в случае с замыканием, возвращающим Optional результат, это — честная игра.
10:54
Рассмотрим следующий сниппет:

[1, 2, 3]
  .flatMap { $0 + 1 }
// [2, 3, 4]

Он компилируется, исполняется и выдаёт результат, но семантика странная: мы не возвращаем Optional из предоставляемого замыкания. Компилятор автоматически “заворачивает” возвращаемое значение, делая это за нас, вот так.

[1, 2, 3]
  .flatMap { .some($0 + 1) }
// [2, 3, 4]

11:22
“Заворачивание” возвращаемого значения вручную показывает некоторую странность во всей логике. Мы всегда возвращаем .some и никогда не «проваливаемся» до nil. И поскольку эта операция НИКОГДА ни при каких обстоятельствах не может «проваливаться», то можно было бы просто использовать map.

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

11:36
Из-за “продвижения до Optional” (Optional promotion) любая операция, работающая с map также будет работать и с flatMap. Может даже показаться заманчивым избегать вообще использования map, поскольку кажется, что flatMap работает всегда, в то время как map иногда не работает. Это слегка прискорбно, потому что мы теряем часть семантического смысла используя повсюду flatMap. При использовании как flatMap, так и map, мы как бы самим кодом ЯВНО документируем, какие операции могут, а какие не могут «провалиться» (fail).

12:08
Что ещё хуже, мы можем изменить наши типы так, что это должно бы привести к ошибкам компилирования, но из-за перегружаемого (overloaded) flatMap и продвижения до Optional (Optional promotion) всё прекрасно компилируется, но демонстрирует неожиданное поведение на этапе выполнения. Например, есть структура User, соответствующая пользователю с Optional именем name, и массив этих пользователей users:

struct User {
  let name: String?
}

let users = [User(name: "Blob"), User(name: "Math")]

12:15
С данным массивом пользователей users у нас есть соблазн использовать map для извлечения их имен names.

users
  .map { $0.name }
// [{some "Blob"}, {some "Math"}]

Но теперь у нас массив Optional значений. В действительности мы бы хотели использовать flatMap.

users
  .flatMap { $0.name }
// ["Blob", "Math"]

12:32
Мы могли бы построить много кода вокруг типа подобного структуре struct User, а затем однажды решить, что имя name в типе User является обязательным. Мы выросли с пониманием того, что мощная система типизации может помочь провести нам рефакторинг кода каждый раз, когда мы решили круто изменить наш тип, [а тут такой сюрприз].

struct User {
  let name: String
}

После перекомпиляции, что же происходит с поведением при выполнении?

users
  .flatMap { $0.name }
// ["B", "l", "o", "b", "M", "a", "t", "h"]

Оно неожиданное! Может и к лучшему, что подобная аномалия была переименована.

compactMap и filterMap

13:18
Итак, с учётом осложнений, пришедших с перегружаемым вариантом (overloaded) flatMap, который был не совсем таким, как другие flatMaps, было решено упразднить его и ввести новое имя. Очень важно помнить, что flatMap над массивами с трансформациями, также возвращающими массивы, и flatMap над Optionals, возвращающий Optionals, не упразднены. Речь идет лишь об аномальном (третьем) методе.

13:48
Изначально было предложено имя filterMap для поэлементного преобразования (mapping) массива с выбрасыванием значений nil. Это метод мог быть определён так:

extension Array {
  func filterMap<B>(_ transform: (Element) -> B?) -> [B] {
    var result = [B]()
    for x in self {
      switch transform(x) {
      case let .some(x):
        result.append(x)
      case let .none:
        continue
      }
    }
    return result
  }
}

14:29
После небольшого «эффекта велосипедного сарая», ставший метафорой закона тривиальности, с вовлечением участников списка рассылки Swift Evolution, неизбежного в таких случаях, имя метода в итоге было изменено на compactMap, и это отлично, поскольку соответствует аналогичному прототипу в Ruby, где есть метод compact работы с массивами, избавляющий массив от значений nil. Продолжим и взглянем на определение compactMap:

extension Array {
  func compactMap<B>(_ transform: (Element) -> B?) -> [B] {
    var result = [B]()
    for x in self {
      switch transform(x) {
      case let .some(x):
        result.append(x)
      case let .none:
        continue
      }
    }
    return result
  }
}

14:53
Это просто переименование — тело функции такое же.

Обобщения (generalizations) filterMap

15:06
Одним из минусов имени compactMap является то, что он крепко привязан к тому, что мы делаем с массивом: мы «сжимаем» его путем удаления nils. Это мешает нам увидеть более широкие возможности применения compactMap.

15:30
А замечательной возможностью имени filterMap является то, что оно могло бы привести к некоторым удачным обобщениям.

15:41
Для начала заметим, что предикат (A) -> Bool над A естественно порождает функцию (A) -> A?:

func filterSome<A>(_ p: @escaping (A) -> Bool) -> (A) -> A? {
  return { p($0) ? .some($0) : .none }
}

Она просто возвращает .some значения, если результат предиката равен true, и .none в противном случае.

16:33
С помощью этой функции мы можем заново реализовать обычный OEM filter над массивами:

func filter<A>(_ p: @escaping (A) -> Bool) -> ([A]) -> [A] {
  return { $0.filterMap(filterSome(p)) }
}

16:41
Попробуем. Мы можем создать фильтр для чётных чисел.

filter { $0 % 2 == 0 }
// ([Int]) -> [Int]

Пропустим сквозь него массив первых десяти целых чисел [при помощи pipeline операции |>].

Array(0..<10)
  |> filter { $0 % 2 == 0 }
// [2, 4, 6, 8, 10]

16:51

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