Краткий ответ

В обобщённом коде следует использовать isEmpty: эта проверка имеет гарантированную сложность O(1). Выражение count == 0 может потребовать полного обхода коллекции и иметь сложность O(n), если конкретный тип не умеет вычислять расстояние между начальным и конечным индексами за постоянное время.

Исторический контекст

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

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

Постановка проблемы

Если обобщённая функция использует count == 0, она может быть эффективной для Array, но неожиданно медленной для последовательной коллекции, где подсчёт элементов выполняется обходом от startIndex до endIndex.

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

Подробное решение

isEmpty проверяет, совпадают ли начальный и конечный индексы коллекции. Для пустой коллекции они совпадают, поэтому проверка не требует посещения элементов.

Свойство count концептуально вычисляется как расстояние между startIndex и endIndex. Для RandomAccessCollection такое расстояние обычно вычисляется за O(1), а для обычной Collection реализация может последовательно переходить от одного индекса к следующему и занимать O(n).

Минимальный пример обобщённой функции:

func firstOrNil<C: Collection>(_ collection: C) -> C.Element? {
    guard !collection.isEmpty else { return nil }
    return collection[collection.startIndex]
}

Здесь isEmpty не только выражает намерение точнее, но и сохраняет эффективное поведение для разных реализаций Collection. Проверка count == 0 допустима, если уже известно, что конкретный тип обеспечивает быстрый count, однако в обобщённом коде это предположение делать нельзя.

Ситуация из практики

Команда написала универсальный валидатор, принимающий Collection, и использовала collection.count == 0 перед обработкой данных. На массивах тесты проходили быстро, но на пользовательской коллекции с последовательным обходом проверка стала линейной.

Вариант с явным приведением к массиву устранил проблему для последующих операций, но добавил копирование и расход памяти. Вариант с count сохранил универсальность, но не устранил потенциальный полный обход.

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

Что кандидаты часто упускают

Одинакова ли сложность count у Array и произвольной Collection?

Нет. У Array количество элементов доступно за O(1), поскольку массив хранит размер. У произвольной Collection count может быть вычислено через обход индексов, поэтому его сложность может быть O(n).

Гарантирует ли isEmpty отсутствие обращения к элементам?

Да, проверка пустоты не должна просматривать элементы. Она определяется по состоянию индексов коллекции: пустая коллекция имеет startIndex, равный endIndex. Это делает isEmpty подходящим для раннего выхода перед дорогой обработкой.

Можно ли всегда заменить count == 0 на isEmpty без изменения результата?

Для проверки пустоты — да: выражения логически эквивалентны. Однако isEmpty предпочтительнее не только по читаемости, но и по сложности. Если значение count нужно для дальнейшей логики, заменять вычисление количества нельзя; в таком случае следует учитывать гарантии конкретного типа коллекции.