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

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

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

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

Ассоциированный тип SubSequence позволяет каждой коллекции определить подходящий тип результата для операций вроде dropFirst, prefix и suffix. Для Array таким типом обычно является ArraySlice, а другая коллекция может выбрать собственное представление среза.

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

Разработчик может ожидать, что после dropFirst получится обычный массив. Это приводит к ошибке типов при передаче результата в API, принимающий [Element], либо к преждевременному преобразованию среза в массив.

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

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

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

Алгоритм, которому достаточно обхода элементов, следует объявлять через ограничение Collection, а не через [Element]:

let numbers = [10, 20, 30]
let tail = numbers.dropFirst()

func sum<C: Collection>(_ values: C) -> C.Element
where C.Element == Int {
    values.reduce(0, +)
}

print(sum(tail))

Здесь tail имеет тип ArraySlice<Int>, но функция принимает его без копирования. Если конкретному API действительно требуется массив, результат можно явно материализовать через Array(tail). Это осознанный компромисс: совместимость с массивным API покупается дополнительным созданием отдельного хранилища.

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

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

В сервисе обработчик принимал только массив идентификаторов, а вызывающий код сначала удалял первые служебные элементы через dropFirst. Прямое использование результата не компилировалось, поскольку возвращался ArraySlice, а не [Int].

Рассматривались два варианта. Первый — сразу выполнить Array(tail): это просто, совместимо с существующим API, но создаёт копию. Второй — изменить обработчик на обобщённый параметр C: Collection: это устраняет копирование и принимает больше типов, но требует проверить, что обработчику не нужны операции, специфичные для массива.

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

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

Можно ли обратиться к результату dropFirst по целому числу?

Нет, общий контракт Collection использует Index, а не произвольное целочисленное смещение. Даже если конкретный срез поддерживает индексы, индекс исходной коллекции может начинаться не с нуля. Для универсального обхода следует использовать for-in, startIndex, endIndex и операции с индексами коллекции.
Всегда ли преобразование SubSequence в Array копирует элементы?

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

Это зависит от конкретного типа и правил его индексов, но универсальный код не должен считать сохранённые индексы или срезы неизменными после мутации исходной коллекции. Мутация может сделать их недействительными или изменить наблюдаемое содержимое. Если срез должен жить независимо от исходных данных, надёжнее явно создать собственную коллекцию, например Array(subsequence).